С чего начать?

[Igel]

Есть задача на проектирование системы. Поскольку кроме разработчиков никто не представляет как это может выглядеть есть только общая идея.
Дальше, мне как начальнику бюро дается задание, выдать проект.
И вот тут писец. Что делать? С чего начать? Какие задания выдать? Как составить проект, как написать ТЗ работникам?
Интуитивно понимаю, что сначала нужен анализ проектируемой системы. (Первая затыка - как провести анализ, что-бы учесть ньюансы)
Слышал что-то про бизнес-процессы.
Затем нужно на основе анализа системы анализировать составляющие компоненты, т.е. более детальный анализ системы и результатом его будет концептуальная модель системы. (Вторая затыка - что это такое, как отображается?)
На основе модели уже расписать что за что отвечает и как работает.
А потом уже выдавать ТЗ на разработку компонентов.
Взял книжку "современные методы описания функциональных требований к системам" А.Коберн - пока только начал, возможно дальше будет понятнее, но вначале книжки идут "варианты использования". В принципе все понятно, но Сабж не раскрыт...

З.Ы. На последок хочу заодно организовать работу в команде, т.е. использовать средства контроля версий и командной разработки. Пока остановился на CVS и WinCVS. Достоинства - бесплатна и многими используется. Есть у нас специалисты по этой проге?

[Alf]

Не очень понятна ситуация... Откуда взялась задача? Если извне, то откуда разработчики уже имеют о ней представление?

Обычно на исходной точке ситуация несколько иная - заказчик думает, что знает, что ему нужно (перечень требований краток и соответствует формуле "сделайте мне красиво"). Далее системный аналитик берет его за пуговицу (или за что там сумеет поймать) и по возможности без рукоприкладства (что не всегда легко) постепенно вытягивает из него, в чем же заключается задача на самом деле. Если задача нетривиальна, для этого строится модель бизнес-процесса, которая способна дать аналитику возможность понять, что происходит в автоматизируемой системе на самом деле. В результате первого этапа мы имеем:
- функциональную модель (IDEF0);
- модель процессов (IDEF3), если нужно;
- диаграмму потоков данных (DFD), если нужно;
- словарь предметной области;
- первый набросок объектной модели области (по возможности).

Второй этап - моделирование данных. На основании моделей, построенных на первом этапе, неоходимо построить модель данных, необходимую для решения задачи. Обычно она включает в себя:
- диаграмму "сущность-отношение" (ERD);
- модель, основанную на ключах (KB);
- полноатрибутную модель;
- модель трансформации;
- модель базы данных.
На этом этапе целесообразно использовать методологию IDEF1X.

Третий этап - разработка кода системы. На основе полученных ранее моделей проектируется программа, которая реализует необходимые функции (этап 1), манипулируя данными (этап 2). Рекомендуемые средства: язык - UML, технология - ICONIX (для проектов попроще) либо RUP (в качестве тяжелой артиллерии).

Последний этап - написание кода. Если предыдущие три проведены добросовестно, никаких особых заморочек возникнуть не должно, обычная рутина.

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

[Alf]

P.S. Совсем забыл рассказать об инструментальных средствах, способных помочь разработчикам в построении моделей.

Построение бизнес-моделей - AllFusion Process Modeler

Моделирование данных - AllFusion Data Modeler

Объектное моделирование - AllFusion Component Modeler, Rational Rose.

Эти инструменты предназначены для сквозного цикла проектирования и достаточно объемны и сложны в использовании. Для работы с UML есть инструменты и попроще. Например, MS Visio может рисовать большинство диаграмм UML, а будучи пристегнут к MS Visual Studio, можно даже производить Reverse Engineering готовых программ с целью получения диаграмм UML. Можно также генерировать скелет описания класса по диаграммме классов.

Есть программы еще проще, которые рисуют диаграммы UML просто как графику, не вникая в их содержание. Помнится, о таких упоминала Never. Возможно, для документирования небольших проектов они вполне подойдут.

[LEON]

Еще, на мой взгляд, важно на каком(их) языках программирования будет вестись разработка.
Если это Java то лучше использовать Rose, которая изначально не была расчитана на работу с .NET. А для работы с .NET Rational выпустила пакет XDE предназначенный, для генерации кода из диаграммы классов.

[Alf]

А на мой взгляд, гораздо важнее не язык кодирования (UML практически нейтрален по отношению к нему), а то, какими средствами производилось проектирование на предыдущих стадиях.

Если бизнес-моделирование производилось средствами AllFusion, то целесообразно продолжить работу в нем же, поскольку родные файлы импортировать все же лучше, чем набивать объектную модель заново. А если сквозной цикл произвдится средствами Rational, наиболее естественно моделировать объекты в среде Rose.

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

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

[Igel]

Запоздало прошу прощения за косноязычность!

Не очень понятна ситуация...

Ситуация возникла из неудовлетворенности существующим ПО, которое разрабатывалось под маленькие задачи без единой идеи. На текущий момент есть несколько программ, которые решают разные задачи, но должны работать в связке. Некая связка(затычка) есть, но процесс работы пользователя усложняется тем, что в свое время связь программ не была предусмотрена и все работает медленно и неэффективно. Сопровождение же всех этих продуктов сопряжено с большими затратами времени (по большому счету на исправление).

Про заказчика: как такового его нету. А тот, что есть, говорит почти так-же (руководство - "пишите план, посмотрим", пользователи - "нас то-то и то-то не устраивает, медленно, криво"). Т.е. собственно идея родилась у меня, хотя витала в воздухе уже долгое время.
Про аналитика: его тоже нету. Я и "заказчик"(хотя это не совсем так) и аналитик (с этим у меня трудно).

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

Наиболее общее представление о системе имеется, но не более. Как строится модель бизнес-процессов - вообще не ясно.
В идеале хотелось-бы иметь методику анализа. Например:
1. Модель бизнес-процессов. От чего она строится?
2. Схемы диаграммы - для чего и как строятся, что в результате.
3. Моделирование данных. И так далее.
...


Что-бы руководствуясь этим мне можно было быстро выработать  линию поведения, типа:
1. Руководитель вырабатывает общие цели,  задачи. (как, что, куда, результат)
2. Распределение аналитической работу: кто какую диаграмму строит, какие процессы описывает.
3. Совещание, проверка, проработка.
4. Распределение заданий, по итогам совещания - разработка конечных ТЗ.
5. ...
В результате должен быть конечный документ, который можно показать руководству и по которому можно строить планы.

Инструментальные средства не столь важно на данном этапе. Приоритет стоит пока в правильной постановке, как это войдет в практику, потребуется это автоматизировать, вот тогда и будем выбирать инструментальные средства. Те-же диаграммы УМЛ можно рисовать и на бумаге.

З.Ы. В общем я понял, что мне нужно все по полочкам разложить. Т.е. прошу всю мыслительную работу сделать за меня... оригинально. Тут есть потенциал - "Система автоматизации руководящего звена".
В общем чувствую посмеетесь надо мной!

[LEON]

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

C Java Rose работает очень прилично. Другое дело, что на Java разработки ведутся реже, мало кто это замечает. А насчет остальных платформ, IBM готовит новый продукт, на смену Розе. XDE собственно, и был выпущен, что бы сделать заглушку для .NET

[Alf]

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

Чтобы произвести анализ задачи, нужно сначала эту задачу досконально понять и документировать, даже если кажется, что в ходе предыдущих разработок все уже выяснено. Я рекомендую воспользоваться для этого методикой SADT (в библиотеке клуба имеется книга Дэвид А. Марка и Клемент МакГоуэн, "МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ", правда, сам я ее еще не читал детально). Если позволяет время (а поскольку заказчик и исполнитель - одно лицо, никто в шею толкать не должен), желательно построить две бизнес-модели: как все работает сейчас ("as-is") и как должно быть по уму ("to be").

В результате этой работы должны появиться следующие документы:
- функциональная модель IDEF0, в которой детально расписано, что должна делать система;
- пакет моделей IDEF3 для нетривиальных процессов, подлежащих автоматизации;
- пакет диаграмм потоков данных DFD, если процесс сопровождается сложным документооборотом и/или связан с обработкой сложных структур данных;
- словарь предметной области, благодаря которому для каждой сущности предметной области останется единственное название, известное всем участникам проекта; поначалу кажется бюрократией, но на деле впоследствии избавляет от массы недоразумений.

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

[Savostkin]

Нетивиальные подходы "программиста-практика" или "Какой может быть борщ, если ТАКИЕ ДЕЛА НА КУХНЕ"

В октябре этого года,воспользовавшись поводом оторваться на час другой от своей "творческой-рутины" ,  особенно, учитывая легально-принудительный повод - участие в конференции по информационным технологим,  стал свидетелем СЦЕНЫ. Ход ее был достаточно стандартным и скучным - денди из Москвы, расслабленно и манерно объясняли дуракам из Ростова-на-Дону почему их программы, компьютеры, технологии,  и тд. САМЫЕ козырные , причем наиболее наглые из докладчиков умудрялись даже менять названия технологий в угоду свом заказчикам (с изумлением узнал что CALSa  вроде уже нет зато есть PLM! ) . ПИПЛ ХАВАЛ и не морщился.  В момент пика невыносимой зевоты, на предпоследнем материале, когда отяжелевшие веки не могла уже удержать никакая невчеловеческая сила, на трибуну, видимо как ударный ход организаторов, энергично вбежал докладчик из Новошахтинска. То что он говорил вызывало чуство поразительное - старые Роствчане пережившие войну, рассказывали, что ели от голодухи САХАР с СОЛЬЮ - их смешали специально при отступлении, тк не успевали вывезти. Вещи, если говорить о точках интелектуального роста, прорывных идеях с одной стороны и безграмотностью и безапеляционностью в суждениях с другой смешались в диком коктейле. Итак в кратце ВЫСТУПЛЕНИЕ :
"Абсолютно шизофреническим является факт что в технологиях ПП до сих пор применяются те же методы, что и при системном программировании. Шизофрения состоит в том системное и прикладное программирование оперируют не просто разными предметами, но предметами не имеющими общих свойств. То есть абсолютно РАЗНЫЕ предметы  обрабатываются ОДНИМ И ТЕМ ЖЕ ИНСТРУМЕНТОМ.....Концепция идеальной технологии создания ПП может сформулирована примерно так:
1/ ТЕХНОЛОГИЯ создания ПП должна оперировать непосредственно понятиями предметной области
2/ ТЕХНОЛОГИЯ  не допускает специальных понятий из области программирования
3/ ТЕХНОЛОГИЯ должна представлять собой систему для ОДНОПАЛЬЦЕВОГО ЗРЯЧЕГО - те мыши достаточно для всего процесса
4/ Тело проекта ПП в ТЕХНОЛОГИИ должно тождественно и оперативно (в реальном времени ) соответствовать исполняемому ПП. Процесс проектирования и исполнения ПП должны проводиться в одном сеансе работы
5/ ТЕХНОЛОГИЯ должна позволять возможность автогенерации простых ПП только на основе исключительно описания ПРЕДМЕТНОЙ ОБЛАСТИ
6/
7/
8/ ПОльзователь ТЕХНОЛОГИИ не обязан иметь ни знаний, ни опыта программирования. Единственное требование - знание ПРЕДМЕТНОЙ ОБЛАСТИ и элементарные навыки работы на компьютере"
"Круто!" - подумалось мне, и ЧТО ДАЛЬШЕ?
А дальше, докладчиком делался следующий пассаж.. "такая технология до сих пор ни кем не создана, и более того нет и малейших подвижек в эту сторону!" Причина - СГОВОР ФИРМ РАЗРАБОТЧИКОВ, искусственно тормозящих прогресс. В качестве конкретного решения докладчиком предлагалась ... собственная разработка (!) в DOSe (!!) по эффективности превосходящая Oracle (!!?).
Вот так  - ни Дуглассов Россов, ни Бучей ни Йорданов и НЕ БЫЛО, не было ни IDAF-ов,  CALS-ов и прочей англоязычной мудрости, потому как СГОВОР.
ЕСли одной фразой резюмировать то, что хотел сказать "Провинциал" - это то, что сечас индустрия информатики - это по сути индустрия ПРОДАВЦА или РАЗРАБОТЧИКА ( Что тысячу раз верно!).  Где ПРОДАВЕЦ ПО создает свои инструменты, технологии, приспособы чтобы с помощъю ПО делать другое ПО. Специалист предметник рассматривается как инертный заказчик, которому правда делаются так или иначе реверансы, но суть остается прежней: В современной индустрии  пока нет целостного инструмента реализации цепочки МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ ->>ИНФОРМАЦИОННАЯ МОДЕЛЬ ->> ИСПОЛНЯЕМЫЙ КОД. Все это создается путем усилий гениев - наших современников в области информатики, пока сшивающих достаточно искусственно,с натяжками,  но с явным и неоспоримым прогрессом, две полярные точки - ПРЕДМЕТНАЯ ОБЛАСТЬ- ИСПОЛНЯЕМЫЙ КОД.
В качестве прорывной идеи, объеденяющей общую философию, именно такой постановки задачи я рассматриваю в большей степени язык универсального моделирования, при всех сложностях болези роста, конвергенции различных идей, с трудом притерающихся к друг другу, сильно пересекающихся между собой и проч. Любой кто реально работал с UML прекрасно знает его слабые стороны (большой специфический объем языка, рыхлость, повторы, и проч), НО. Идея UML - КРАСИВАЯ и значет ВЕРНАЯ по сути! На этой позитивной ноте я бросаю перчатку скептикам и готов обсудить тему под следующим углом:
Умница Alf разжевал уважаемым юзерам существующее фактически состяние  дел по моделированию как бизнесс-процессов так и дальнейшую трансформацию IDEF - модели (ее модификации не меняют дела) в модель информационную, проектирование БД и далле в исполняемый код.
Суть проблеммы как я ее вижу в плане тактическом - как UML можно использовать для МОДЕЛИРОВАНИЯ ПРЕДМЕТНОЙ ОБЛАСТИ? В плане стратегическом - как будет выглядеть и на какой концептуальной основе построен целостный инструмент создания готового ПО только исходя из знания предметной области.


МИНСЕЛЬХОЗ России.
 


 

   

[Alf]

Игорь, привет, дружище!

Рад, что ты наконец-то присоединился к нашей пестрой компании. 

Собственно, в твоей вступительной речи я увидел два наиболее интересных момента:
1) Выступление оратора из Новошахтинска;
2) Использование UML для моделирования предметной области.

Вот мое мнение по этим вопросам.

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

Раз нет такого вопиющего противоречия - значит, не должно быть и принципиально различных методов разработки программ. Метод, собственно, известен с самого начала развития информатики как науки - "разделяй и властвуй", т.е. дели сложную задачу на подзадачи попроще, те, в свою очередь, дели дальше, и так до тех пор, когда каждая отдельная задача не станет тривиальной. А там начинается обратный процесс - из множества мелких решений собирается глобальное решение для всей задачи. Редкая статья Дейкстры обходится без этой прописной истины. А все многочисленные технологии, изобретенные в помощь программисту, служат той же цели - помочь разделить задачу на более мелкие, по возможности гарантируя при этом, что сумма их решений и есть искомое решение задачи. Ситуация та же, что и в математике - если теорема слишком сложна, докажи сначала несколько лемм, а с их помощью уже и все утверждение.

Теперь что касается идеи товарища из народа - создание программ без программирования, т.е. автоматическая генерация кода исходя исключительно из модели предметной области. Тут он не является первопроходцем - эта мечта хоть и не так стара, как философски камень или вечный двигатель, но тоже насчитывает не один десяток лет. В частности, Дейкстра в своих статьях подвергал конструктивной критике подобные идеи, не буду загромождать и так немалый пост объемными цитатами, они есть среди моих переводов. Или вспомни судьбу проекта компьютеров 5-го поколения, когда была поставлена задача - к 2000 году реализовать общение человека с машиной на естественном языке, исключить необходимость задания алгоритмов - машина сама должна находить решение поставленной задачи, и.т.п. Конечно, этот проект обеспечил колоссальный прорыв в теории и практике искусственного интеллекта, и в немалой степени его провал обусловлен смертью Мото-Ока... (Хотя мне как-то приходила мысль, может быть, он как настоящий самурай сам ушел из жизни, избежав насмешек по поводу провала?.. Кто его знает...)

Так или иначе, программы без программистов в обозримом будущем создаваться не будут. Хотя нам периодически подкидывают новые технологии, посредствлм которых якобы программировать будет легко и быстро, если верить рекламе (вспомним Delphi, Java, .NET)... Однако на деле программер получает еще несколько пухлых томов руководств, без штудирования которых почему-то ничего не получается. Можно обвинять в заговоре кого угодно - Гейтса, Oracle, Буча, масонов... Однако воз и ныне там.

2) Идея использования UML для моделирования предметной области не нова. Собственно, она так и напрашивается из самого названия - если это язык моделирования, почему бы тогда не моделировать все на свете с его помощью?

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

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

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

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

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

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

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

Однако у нас прямо переписка Энгельса с Каутским получилась по объему 

[Гром]

Разрешите в роли Шарикова
НЕ согласен я с обоими Шутка...

На деле же - у меня был такой пример работы с системойкоторая сама создавала код - это СУБД Clarion в 1990 году у нас была очень даже распространена. От нее изначально пошли собственно Визарды и идея создания полного Проджекта, у нас по крайней мере.

Я честно говоря сам никогда ни УМЛ ни какими то другими средствами разработки не пользовался...

Почему - честно признаюсь в одной детали.

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

2. После начала разработки на производстве поначалу я был как бы второстепенным членом в планировании задач. Молодому спецу мало доверяли крупных разработок побольшей части задавая задачу словами - на взходе это на выходе то, или задавали параметры - берешь с такого-то интерфейса данные и выводишь таким-то образом - типа того. Естественно, что и эти задачи помещались у меня в голове вполне спокойно. Тем более, что средой был ДОС и сложных систем на тот момент с параллелированием процессов я не наблюдал.

3. На этом этапе - когда я попал в серьезную разработку и мне вложили в руки проект - уже были все эти студии и много чего еще - так как я имел перерыв в работе около 4-5 лет.
Многое пришлось учить заново, и тут я наткнулся на факт, что при любом размере системы могу разделить ее на кубики. Т.е. сначала придумывается общий концепт на базе ТЗ. Или на базе совещания
Потом продумывается структура блоков глобально, для примера - тестовая программа для оборудования выпускаемое фирмой.
Программа разделялась на три части:
а) User Interface
б) Интерфейс с самим железом
в) Тестовые процедуры сами собой.
Потом это дробиться на куски - потом те куски уменьшаются уже до кода - а общий концепт держиться в голове и обмен данными в программе вполне можно уместить на листике формата А4 в несколько строк....

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

4. Последнее

НА сегодняшнем этапе - когда любая система - от реал-тайм до прикладного контроля или теста - от програмки утилитки до подъема целой платформы с спец задачей внутре, всегда умещается в тренированной башке
Это по прежнему дает мне возможность забывать на время работы с кодом общую задачу, решая локальную процедурную или как максимум задачу в рамках одного блока.
В самом сложном случае - когда работа происходит при больших нагрузках - как пример - работа прокси сервера на своем протоколе с массой клентов и массой процессов и данных проходящих по трубе программы - сервера, все равно можно спокойно удержать в голове уровни вложения и отработать всю систему блоков и данных как обычный State-Machine (конечный автомат) который вполне уляжется в голове...

Отсюда вопрос - покажите задачу с которой не смогут справится такие вводжные данные и где единственным средством для полного понимания выступит УМЛ.
 

[LEON]

Гром
№3 то что ты описал, это шаблон MVC = Model - View - Controler. Эту модель придумали более 30 лет назад.
№4 Не понятно, ты не встречал, задач на сенгодняшний день, которы полностью в голове одного человека не умещаются?
Не зря, у нас сейчас появилось целое направление компании интеграторов.
Вот ссылка, на решения одной из компаний на современном рынке IT
http://www.topsbi.ru/pages/rus/solutions
Ты просил предметную область, и задачу, которая не помещается в голове у одного человека, вот она ))

Alf
По моему можно разделитьпрограмистов на системщиков, и высокого уровня.
Системщики, занимаются системой )), или программированием на железе.
Высокого уровня разработкой больших систем.
А пример с проводником, это не совсем показатель. Многоэтих самых проводников надо? К сожалению или к счастью, маленькие  прикладные программы отмирают, за  не выгодностью. Проводник, он поставляется с ОС, ОС это системное ПО )), => Проводник это системное ПО. Сейчас очень четко видны грани между высокоуровневым и низкоуровневым ПО. Я например, в ближайщем будущем, не поверю, что можно спроектировать УП, для микропроцессора, с помощью CASE средств.

[Alf]

...
Сейчас очень четко видны грани между высокоуровневым и низкоуровневым ПО. Я например, в ближайщем будущем, не поверю, что можно спроектировать УП, для микропроцессора, с помощью CASE средств.

Наверное, вместо микропроцессора все же имелся в виду микроконтроллер. Потому как на микропроцессорах все персоналки делаются, и там уж сам бог велел использовать CASE.

Если я угадал, то опять же не вижу причины отказываться от CASE. В одном из букварей по UML в качестве примера как раз взята разработка firmware для автомата по продаже газированной воды. И очень удачно IMHO получилось: разработали модель прецедентов (для моделирования сценариев взаимодействия аппарата с клиентом и обслуживающим персоналом), дальше определились с основными блоками устройства, построили конечный автомат для реализации логики работы... Проект практически готов - осталось реализовать логику в виде кода, и все.

[Alf]

Гром, вы хочете задач? Их есть у нас! 

Если серьезно, во всех перечисленных случаях ты получал ТЗ, как сам признался. То есть знал, что нужно делать, и искал путь - как.

Анализ бизнес-процессов как раз и нужен для того, чтобы построить корректное и согласованное ТЗ, точно следуя которому, разработчик сможет разработать продукт. Когда задача понятна, без него (анализа, а не ТЗ!) вполне можно обойтись. Взять тот же пример с нашим форумом - мы вполне могли позволить себе обойтись без бизнес-модели и сразу приступить к моделированию объектов и данных. Или упомянутый тобой прокси - как бы сложен он ни был внутри, постановка задачи уместится на тетрадном листике, ибо все прокси делают одно и то же: скрывают Intranet от Internet. Бизнес-модель проксирования - это даже забавно было бы 

А вот возьми задачу, скажем, масштаба SAP/R3. Ну или что-нибудь более реальное, например, автоматизация небольшой мануфактуры. Во-первых, не вместит твоя голова столько разнородной информации, не резиновая она. Во-вторых, не напишешь ты столько кода в одиночку. А если и напишешь, то мануфактура к тому времени уже разорится, не дождавшись. Значит, придется работать в команде. Следовательно, нужно вести проектную документацию. Можно, конечно, и не вести... Результат описан здесь: https://forum.shelek.ru/index.php/topic,258.msg89754.html#msg89754

У моей группы задачи еще поскромнее - например, биллинг для частной телефонной компании, точнее, та его часть, которая связана с взаимодействием с коммутационным оборудованием и сбором информации. Однако после того, как внедрил у себя SADT и UML, ситуация стала куда управляемее, чем раньше.

[LEON]

Да, я говорил про микроконтроллеры.
С помошью UML можно спроектировать структуру программы, ее взаимодествие с внешними устройствами, это даже намного удобнее чем рисовать структуру в своих терминах, или блок-схемах.
Но все таки CASE средств для вот таких вот программ https://forum.shelek.ru/index.php/topic,258.msg94524.html#msg94524
для работы на ASM еще не придуали, и в ближайшем будующем вряд ли придумают.
Отсюда, как мне кажется, и разделение: На программные продукт, который можно удержать в голове (программы для MCU вполне влезают в одну голову), и на большие системы, которые не влезают. Использование CASE для маленьких разаработок, когда сам MCU стоит менее 100р, экономически не выгодно. ))

[Lex]

Leon, это все от микроконтроллера зависит, и что ты на нем делать собрался. В ветке про эмбедед системы я писал, что микроконтроллеры разные бывают от 8-ножечного пика, до мотороловских монстров с PowerPC ядром и Ethernet , USB  и т.д. на борту. Да и задачи бывают разные.

Для себя я сделал вывод, что CASE средства в первую очередь нужны, когда работает группа людей, либо когда народ четко не может представить, чего же он хочет.

[Alf]

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

Будучи частью системы, контроллер просто вынужден с ней взаимодействовать: получать извне команды, передавать обратно данные и т.д. Следовательно, нужен некий протокол для взаимодействия. А тут уж при моделировании очень кстати и автоматные диаграммы, и диаграммы обмена сообщениями, которые предусмотрены в UML.

Конечно же, отдельный проект посредством CASE специально для каждого контроллера никто не разрабатывает, проектируется система в целом, включая серверы и рабочие места операторов. Однако и для контроллеров в проекте отводится своя часть, тем более что нестыковки в интерфейсе загубят всю систему.

Кстати, программирование PIC-контроллеров для проекта производилось, насколько я видел, на языке С (сам непосредственно не программировал их, только выдавал спецификации на firmware). Разработчик контроллеров  говорил, что удалось очень эффективно применить готовые библиотеки, так что сделал работу на удивление быстро и качественно. ASM или применялся ограниченно, или не применялся вовсе, тут уж я не в курсе. Может быть, конечно, код получился не столь компактным, как в описанном случае, ручаться не буду, однако в память контроллера уместился. Зато получил контроллеры в срок, к качеству программ претензий нет, и при необходимости расширить функциональность опять же проблем не возникало.

[LEON]

Lex
Это я знаю 8)

Alf
То что ты сейчас описал, когда MCU модуль является частью большой АСУ, это пример, когда CASE средства используются для проектирования всего кроме контроллера, т.е. модуль микроконтроллера представляет собой компонент, на диаграмме компонентов, или варианты использования - черный ящик, с известными входами/выходами. Но для программирования самого микроконтроллера используются другие технологии. UML используется для моделирования всего, снаружи микроконтроллера, и для построения алгоритмов внутри. Но UML это не есть CASE, а я говорил про использование CASE именно для программирования контроллеров.

А на языке Си можно программировать многие микроконтроллеры, но не все, и это тоже зависит от задачи.

[LEON]

Возможно я что то путаю, но я под термином CASE всегда понимал Computer Aided Software Engineering. А UML не попадает под это определение. То что многие CASE средства используют в себе  UML, не делает UML програамным продуктом.

[Alf]

LEON, не путаешь, так и есть. Конечно, никакой из языков сам по себе не является средством автоматизации. CASE-средства - это Rational Rose, или AllFusion Object Modeler, или хотя бы MS Visio. Равно как Pascal не является средствм CASE, а Borland Delphi - является.

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

[LEON]

Да никуда я не клоню, я почти со всеми тезисами согласен.
А по сути  дела, если в рамках темы C чего начать? то ничего, А если с того момента, когда разговор пошел про разделение задач, то там я попытался высказать свои мысли. Кратко, то что использование CASE средств (НЕ рисовалок, а именно CASE) для разработок системного уровня, сейчас практически не применимо. Даже Visio имеет функции обратной генерации, построение модели по коду.

Небольшое отступление:
В настоящее время, перед разработчиками больших систем стоит задача разрабатывать большие системы, как ни странно. А что нижно для более эффективной разработки? Уменьшение трудозатрат, и стоимости готового решения. И решение для этой задачи существуют, это средства автоматизации. Сейчас автоматизации уже подходит к такому уровню, что по модели технологического процесса возможно получать готовые решения, в виде кода, набора компонентов, и программных продуктов. Это самое величайшее достижение в уменьшении трудозатрат. Как было раньше (не совсем раньше, когда CASE не было, а раньше лет 5 назад), строим модель бизнес процесса, строим модель системы, кодируем, внедряем, внесение изменнений на этапе кодирования в бизнес модель серьезно может повлиять, на уже готовую часть работы, ее предется переделывать.
Этому процессу предлагается альтернатива в виде сквозной разработка начиная с модели, заканчивая готовым решением. Оговорюсь сразу, что пока таких средств на рынке нет, они все еще находятся на стадии разработки. Но тут главное не решение, а вектор направления, куда все движется, в какую сторону.
Для интересующихся могу привести аналогию с компиляторами ЯВУ.
В простейшем случае, процесс разработки программ на ЯВУ представляет собой:
- Проектирование программы на ЯВУ
- Ассемблирование
- Генерация исполняемого кода.
Представим себе ситуацию, что нам надо поменять значительную часть функциональности ПО написанного на ЯВУ. Что мы делаем, берем код, и переписывем, и компилируем заново. Никому в голову даже мысли не приходит, о том, что уже готовую программу нужно отлаживать на асме или в машинных кодах. Глупость, не правда ли? А почему такая ситуация сейчас в пректировании АСУ? Внося изменения в бизнес процесс приходится заново проходить все стадии разработки. Экономически не выгодно.

Так вот, что я хотел сказать про CASE и системное программирование. Что в ближайшем будующем, бля проектирования задач на железе, CASE применятся не будут (НЕ рисовалки). UML это замечательно, IDEF тоже, но не применимо.

[Alf]

...Представим себе ситуацию, что нам надо поменять значительную часть функциональности ПО написанного на ЯВУ. Что мы делаем, берем код, и переписывем, и компилируем заново. Никому в голову даже мысли не приходит, о том, что уже готовую программу нужно отлаживать на асме или в машинных кодах. Глупость, не правда ли? А почему такая ситуация сейчас в пректировании АСУ? Внося изменения в бизнес процесс приходится заново проходить все стадии разработки. Экономически не выгодно.

Я полагаю, изменение изменению рознь. Одно дело, когда принимается решение прекратить отливать какой-нибудь коленвал у себя, а заказывать его смежникам. Такое изменение процесса вряд ли потащит за собой кардинальное перепроектирование системы технологической поддержки производства. Другая крайность - завод по производству баллистических ракет по конверсии перепрофилируют на производство подгузников. Тут уж изменения будут такого масштаба, что полное перепроектирование программного обеспечения покажется мелочью.

А вообще действительно грамотно спроектированное программное обеспечение просто обязано давать какую-то свободу маневра, адаптируясь к изменениям бизнес-процесса. Взять, например, SAP R/3. Эту систему весьма успешно используют во всем мире энергетики, нефтяники, автопромышленники и т.д. Не думаю, что их бизнес-процессы сходны, как близнецы. Однако хорошо продуманная система способна к ним адаптироваться.

Так вот, что я хотел сказать про CASE и системное программирование. Что в ближайшем будующем, бля проектирования задач на железе, CASE применятся не будут (НЕ рисовалки). UML это замечательно, IDEF тоже, но не применимо.

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

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

Первая:

Для разработчиков встроенных приложений - Rational Rose RealTime, обладая понятной средой визуального моделирования, мощной нотацией, процессами и инструментами, отвечает всем требованиям разработчиков встраиваемых приложений реального времени. Rational Rose RealTime поддерживает индустриальный стандарт UML, разработку конструкций реального времени, генерацию кода и исполнение моделей на протяжении всего жизненного цикла.

Вторая (предлагается программное обеспечение для семейства одноплатных компьютеров/контроллеров VM642/662):

Системы разработки прикладного программного обеспечения: профессиональные кросс-системы разработки Ассемблер/С/С ++ и др. в среде MS-Windows и рабочих станций на базе UNIX -/SUN/SG/HP/IBM, CASE-системы разработки PLC/МЭК 1131 ISAGraf и Fuzzy Logic на платформе MS-Windows.

В таких случаях гораздо уместнее фраза вроде "лично я в ближайшем будущем для проектирования задач на железе CASE применять не буду" или же "лично мне неизвестны успешные случаи применения  CASE для проектирования задач на железе". А вот так, сразу за всех... Билл Гейтс тоже в 1981 году обмолвился, что никому никогда не потребуется более 640 килобайт оперативной памяти. Теперь ему стыдно, наверное.

[LEON]

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

Крайность с заводом баллистических ракет, и подгузниками, по  моему, это уже совсем крайность. В нашей стране всякое может произойти бывает, но такое... Я говорил, про автоматизацию процесса разработки АСУ. Возможность получать готовый программный комплекс на основе модели бизнес процесса, тогда не будут страшны даже такие изменения. По моему, все таки, аналогия с программой на ЯВУ вполне применима. Кардинальное изменение процесса производства, с ракет на подгузники, ведет за собой полное пере моделирование технологических процессов. Аналогия, изменения большой части кода программки. После изменения модели (кода программы) мы (в теории) тут же получаем готовый продукт - готовую систему (исполняемый код для программы).

Взять, например, SAP R/3. Эту систему весьма успешно используют во всем мире энергетики, нефтяники, автопромышленники и т.д. Не думаю, что их бизнес-процессы сходны, как близнецы. Однако хорошо продуманная система способна к ним адаптироваться.

SAP не совсем удачный пример, он состоит из большого числа различных модулей, для каждой отрасли свои. Больше похоже на MS Office. Word и Excel разные вещи, используются для разных задач, и на выходе дают разные результаты, однако их объединяет то что они находятся в одном пакете MS  Office.

Под громким названием Rational Rose RealTime скрывается все та же самая, знакомая нам, роза. Из нее убрали все языки программирования, для компиляции кода на Си и Си++ требуется внешний компилятор, снабдили дополнительной библиотекой шаблонов, для проектирования СРВ. Вы большей степени, все эти функции, и унаследованные от розы, и вновь приобретенные не рассчитаны на проектирование СРВ на низком уровне. Они больше подходят для программирования под ОС, а не под кристалл. То что мы так уцепились за проектирование программного обеспечения для всяких там железяк, просто был опыт этого  самого проектирования. И при разработке таких вещей не получается уйти от кода, а при разработке больших систем, вполне возможно, разработчикам вообще обходится без кода.

Еще некоторое время назад, в разработку, бросались сразу с головой, практически без анализа, зачастую без проектирования, когда самым важным являлся процесс кодирования. Это можно подтвердить составом команды разработчиков, для среднего проекта (1 менеджер, 1 руководитель, 1 архитектор, от 3 программистов (кодеров), без тестировщиков) Причем некоторые должности могли совмещаться, архитектор, менеджер и руководитель могут быть одним лицом. Сейчас, для построения проекта даже чуть более сложного требуется совсем другая команда (1 менеджер, 1 руководитель, 1 архитектор, 2 аналитика, 1 разработчик, 2 тестировщика, и один или несколько консультантов со стороны). Не знаю, но по моему это наглядно показывает, что код это не самое главное в проекте, получить код, или готовое решение, это ЦЕЛЬ проекта, но не самоцель.

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

программное обеспечение для семейства одноплатных компьютеров/контроллеров VM642/662

Это тоже не совсем подходящий пример, когда над микропроцессором появляется ОС, его программирование, уже переходит, из программирования для железки, в программирование для ОС. Для таких проектов возможно, есть плюсы в использовании CASE средств, по тому как такой процессор вместе с его ОСРВ стоит уже далеко не 100р, и затраты на покупку CASE будут не столь внушительными и окупятся.

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

Теперь ему стыдно, наверное.

Что однако не мешает ему быть самым богатым человеком на земле.

[Alf]

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

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

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

Кстати, аналогия с компиляцией программы, написанной на ЯВУ, для процесса проектирования системы неправомерна. Синтаксис и семантика языка программирования известны, поэтому компиляция исходного текста в машинный код - хорошо формализуемый процесс, с которым компьютер прекрасно справляется (для таких задач он и создан). Исходный текст программы представляет собой запись алгоритма, то есть уже готовое решение задачи. Компилятор лишь переводит его с одного языка на другой, низкоуровневый, однако при этом не меняет порядок и суть выполняемых операций (строго говоря, в процессе оптимизации может и поменять, но на результате выполнения программы это не отразится). Никакие вольности тут не допустимы.

Бизнес-модель, как я уже ранее описывал, - это абстракция другого рода (речь идет о функциональной модели IDEF0). Это - структурированный набор функций, которые необходимы для осуществления деятельности объекта моделирования. Говорить о трансляции из бизнес-модели в машинный код не имеет смысла, поскольку бизнес-модель не является техническим заданием - это лишь формализованное представление функций, работающих на объекте. Не все из этих функций можно и нужно автоматизировать. В процессе составления технического задания заказчик указывает, какие из этих функций необходимо автоматизировать и каким образом. И лишь после этого можно говорить о машинном коде, поскольку бизнес-модель является лишь приложением к техническому заданию, хоть и очень важным.

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

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

Ладно, написано слишком много... Резюме:

1. Автоматизированное проектирование и автоматическая генерация кода не есть синонимы, не следует переоценивать реальные возможности первого.
2. Генерация машинного кода по тексту программы на языке высокого уровня и генерация программы по описанию задачи - две большие разницы. Первое вполне реально, второе - в общем случае нет.
3. Среди средств UML немало таких, которые могут оказаться весьма полезны при разработке программного обеспечения встроенных систем независимо от факта наличия у них операционной системы. (Кстати, а кто-нибудь вообще встречал в описании UML хоть слово про операционную систему?)

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

[Dimka]

А нельзя ли всякий бизнес-процесс свести к процессу документооборота? Я информационных систем видел не очень много, однако на тех, которые попадались, пока что сформировал мнение, что всякое действие в реальном мире в системе отражается передачей и обработкой информации. Пакеты информации (документы) обычно имеют иерархическую структуру атрибутов. Такие функции как "послать документ", "принять документ", "подписаться/отписаться на/от рассылку/и", самые формы редактирования документов (с атрибутами известных типов) - вещи довольно унифицированные. Т.е. каркас системы вплоть до черновиков форм по созданной модели построить можно автоматически. При достаточной наработке библитек уровня представления данных размер кода, не требующего вмешаетльства программиста, будет велик. По сути программисту остаётся лишь исправить экранные формы (автомат может сделать их стандартными, но некрасивыми или неудобными с точки зрения пользователя) и вписать нестандартные алгоритмы обработки атрибутов документов - по сути, расширение стандартных библиотек собственными компонентами.

Тогда основное время будет уходить на разработку модели (работа аналитика). Всякие операции по сопровождению тоже начнутся с внесения изменения в модель, при наличии компонент со специфическими алгоритмами вмешательство программиста опять будет минимальным.

У меня, например, сейчас главная проблема - сопровождение одной не очень большой системы. Модель её, 1,5 года наза описанная, сейчас безнадёжно устарела. В систему вносили изменения разные люди не утруждая себя документированием изменений в модели. По сути приходится разбирать код, восстанавливая по нему функционал системы - трудозатраты в разы большие, нежели изучение модели на, скажем, UML описанной. И всё из-за отсутствия удобного CASE-средства, которое в вышеописанных понятиях обращения документов могло бы 80% кода генерировать. Единственно, проблема тестирования. Так как генерируемый код неоднозначен и требует ручного наполнения местами, то тестировать приходится всю систему целиком. Но для задач тестирования тоже есть средства автомазиации.

[Alf]

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

Полагаю, что в общем случае любой бизнес-процесс свести к документообороту не получится. Равно как и не любая информация сводится к документу.

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

Во-вторых, такой односторонний подход может помешать нам выполнить очень важную часть процесса автоматизации - реинжиниринг. Располагая детальной моделью бизнес-процесса, можно произвести его ревизию, выявить избыточные функции, нерациональные решения и т.д., а по результатам ревизии впоследствии произвести оптимизацию (недаром обычно строится пара бизнес-моделей - as is и to be). Оптимизация бизнес-процесса с высокой степенью вероятности повлечет за собой изменение документооборота, что должно быть учтено при построении системы.
Рассматривая изначально деятельность автоматизируемого объекта через призму его документооборота, мы вряд ли сможем произвести подобную оптимизацию, поскольку в этом случае мы располагаем лишь косвенной информацией, обслуживающей процессы.

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

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

Основной документооборот, связанный с этой деятельностью, состоял из протоколов периодических замеров уровня масла в емкостях (фактически замеры производились деревянной линейкой), а также накладных приема партий масла из цеха и отпуска масла в авто- и железнодорожные цистерны. Не буду вдаваться в детали этого "бизнес-процесса", скажу лишь, что при диаметре дна цилиндрического бака 13 метров изменение уровня на 1 см соответствует более чем тонне масла. То есть достаточно слегка отклонить линейку от вертикали (случайно или намеренно), и грош цена такому учету. Да и измерения производились не каждый день.

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

Само собой, это изменило документооборот цеха. Вместо журнала, в который время от времени заносились результаты измерений рейкой уровня масла в баках (а о точности этих измерений я уже говорил, к тому же плотность масла зависит от температуры, так что уровень может изменяться даже без прихода/расхода), каждые сутки система выдает график изменения количества масла (в тоннах), а также таблицу сливов/заливов. Дежурному диспетчеру остается лишь подшивать графики в папку.

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

[Dimka]

Хм, я ж не об анализе бизнес-процессов, а об автоматизации генерации кода. Получается изменение точки зрения: на стадии анализа не реальную систему нужно рассматривать через призму документооборота, а создаваемую информационную систему через призму документооборота. Реинженириг остаётся вместе с реальной системой. В приведённом примере журнал как был, так и остался (с точки зрения информационной системы не как программного комплекса, а вообще), изменилась лишь структура документа. Значение сигнала от датчика, записываемое в БД - это тоже документ. Под документом я ни в коем случае не понимаю бумажку.

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

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

Это старинный вопрос кибернетики (и философии): что есть информация с точки зрения системы. Ведь CASE-средство умом не обладает, ему разницы между подсолнечным маслом и телекоммуникационным спутником не "понять", оно и понимать то не умеет. Т.е. говорить о том, что информация есть в системе будет неверным, информация есть в головах аналитиков, разработчиков и пользователей. Абстрагирование от системы в конкретной предметной области к информационной системе вообще.

[Alf]

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

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

[Dimka]

возможно и так

[LEON]

1. Автоматизированное проектирование и автоматическая генерация кода не есть синонимы, не следует переоценивать реальные возможности первого.
2. Генерация машинного кода по тексту программы на языке высокого уровня и генерация программы по описанию задачи - две большие разницы. Первое вполне реально, второе - в общем случае нет.

Я думаю, что я не путаю термины автоматизированный и автоматический.
А по второму, теперь уже не только я категорично отрицаю прогресс Я все таки считаю, что это возможно.
Могу привести, небольшую часть курса "Автоматизация и Интеллектуализация Процессов Управления"

Начало. Заметки об Автоматизации.

1. Диаграмма переноса модели.
J – Исследователь
Это моделирующий субъект, тот кто решает задачу автоматизации.
H – Объект исследования.
Объект автоматизации
Comp – Вычислительная среда.

Битая ссылка на картинку

J строит модель H и реализует эту модель в Comp.
Стрелка  (J, Comp) - процесс моделирования. Процесс переноса модели из языка моделирования (естественный язык) в язык вычислительной среды (SQL, UML, …).

В данном случае моделированием занимается исследователь. Но ведь можно попытаться смоделировать поведение иссследователя. Тогда получается вот такой рисунок.

Битая ссылка на картинку

В качестве объекта исследования берется сам исследователь. Это и есть процесс автоматизации.

2. Диаграмма кристаллизации алгоритмов.

Битая ссылка на картинку

Базовые типы данных: Булевы, строки, числа (целые, вещественные). Это типы данных вычислительной среды.

Математические типы данных:
A – Множества
AR – Множества с отношениями
AF – Множества с операциями
AFR – Множества с отношениями и операциями
В математических типах данных строится модель и метод решения задачи.

Абстрактные типы данных, прослойка, между математическими и базовыми типами данных. Посредник.

3. Диаграмма инфологического переноса. (Перенос инфологической модели)

Битая ссылка на картинку
Тут вроде бы дополнительных объяснений не требуется, и по рисунку все видно.

4. Объединение диаграмм
Битая ссылка на картинку

(1)
1833
Счетная  машина Бэббибджа. Всю работу по программированию выполняет человек.

(2)
~ 1945
Работы Неймана и  ENIAC-1. Появляются базовые типы данных, и часть работы исследователя переносятся в вычислительную среду.

(3)
~1960
COBOL и структурные типы данных. Исследователю уже не надо оперировать базовыми типами данных, он может работать в абстрактных типах данных.

(4)
~1970
Кодд и концепция реляционных БД. Работа исследователя перемещается в проектирование физической БД

(5)
Джекобсон и первые CASE средства и нотации.
Objectory 1.0 1988
И
Objectory 3.8 1995 года
Еще один шаг в сторону уменьшения трудозатрат. Исследователь уже находится в концептуальной схеме БД.

(6)
Сейчас мы как раз обсуждаем, и переживаем вот этот этап. Или уже почти пережили. Исследование концептуальной модели предметной области.

Что будет дальше? Я думаю, что видно, в какую сторону движется автоматизация.

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

3. Среди средств UML немало таких, которые могут оказаться весьма полезны при разработке программного обеспечения встроенных систем независимо от факта наличия у них операционной системы. (Кстати, а кто-нибудь вообще встречал в описании UML хоть слово про операционную систему?)

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

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

Кстати, то что Джекобсон позаимствовал диаграммы со своего предидущего места работы, это не факт. Конечно это очень похоже на правду, но сам он об этом никогда не говорил.