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

[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 я могу сделать все тоже самое. Алгоритмы записать блоксхемами. Состояния конечными автоматоми.

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

[Alf]

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

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

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

Кстати, судя по картинке №4, с 1970 года алгоритмы "кристаллизует" исключительно компьютер. Забавный подход... Интересно, сам художник работал с оборудованием и софтом 70-х годов? Или хотя бы книги читал этого времени?

Хотя, собственно, чего тут развозить... Одной фразы

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

вполне достаточно. Моделируем, значит, на естественном языке, а вычислительная среда у нас понимает исключительно SQL с UML. Избави господь от такого курса "автоматизации и интеллектуализации"...

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

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

P.S. Вот это:

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

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

[LEON]

"Техника дойдет до такого совершенства, что человек сможет обойтись без себя". Ст. Ежи Лец

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

По моему, здесь обсуждается не автор заметки.

Жаль, практической пользы от этих треугольников куда меньше, чем от того же UML.

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

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

Это наверное самый сложный вопрос. Когда я в первые узнал об этом мне это тоже не совсем понравилось. Возможно, здесь ошибка в терминах, на мой взгляд, более подходящим термином, является не база данных, а база знаний. Без БД сейчас не обходится ни одна крупная система. БД является основой любого проекта (если мне кто-нибудь приведет обратнеы примеры, буду рад). Уже давно пришли к тому, что знания лучше представлять, не базовыми типами данных, и не абстрактными, а математическими, и выше. Самый тяжелый момент в понимании, это стрелка, на 5 рисунке, от одной диаграммы к другой. AR - Множества с отношениями, это и есть реляционная модель данных.
Еще можно вспомнить, что нам обещают микрософт в 2006 году. Windows Longhorn у которого файловая система представляет собой гибрид NTFS с SQL Server.

Кстати, судя по картинке №4, с 1970 года алгоритмы "кристаллизует" исключительно компьютер. Забавный подход... Интересно, сам художник работал с оборудованием и софтом 70-х годов? Или хотя бы книги читал этого времени?

Наверное судя по картинке №5. С 1970 появилась возможность оперировать с математическими типами данных.  Насильно никто прогрессом пользоваться не заставит. Я сейчас, в 2005 году, наблюдаю примеры, когда под IBM PC люди пишут на АСМе.
Художник с оборудованием и софтом семидесятых не работал, а книжки читал. По тому что как минимум на свет появился в 80-х.

Хотя, собственно, чего тут развозить... Одной фразы

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

вполне достаточно. Моделируем, значит, на естественном языке, а вычислительная среда у нас понимает исключительно SQL с UML. Избави господь от такого курса "автоматизации и интеллектуализации"...

Почему такая тяга переврать написанное. Если проблема только в одной фразе, то ее можно и заменить. В скобка обычно пишут примерытого о чем говорят, ключевым терминами сздесь являются: язык моделирования и язык вычислительной среды Естественный язык вполне может быть языком моделирования, так же как и SQL и CASE могут быть языками вычислительной среды. Еще там в конце стоят три точки. Понятие вычислетельная среда, это не только IBM PC, это любое программируемое вычислительное устройство. В идеале, отвесающее принципам фон Неймана.

P.S. Вот это:

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

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

Да, а в коболе не было структур? Вполне возможно, я и ошибаюсь, с коболом 59 я действительно не работал, работал только с VisualAge Cobol, но как миниум два источника говорят, о том, что структуры все таки в коболе были.
http://objectz.com/pp/part2.asp
http://schools.keldysh.ru/sch444/MUSEUM/LANR/cobol.htm

[Alf]

По моему, здесь обсуждается не автор заметки.

Разумеется, нет. Никаких конкретных личностей. Обсуждается явление в целом. Человек попросил конкретных рекомендаций, как ему правильно произвести анализ задачи и в дальнейшем спроектировать систему. Взамен получает набор общих фраз философской направленности и несколько абстрактных фигур. Может, в них и есть какая-то глубокая мудрость, но что она дает практикующему программисту?
Может, конечно, я излишне придирчив. Хорошо бы спросить у самого Igel'а, помогли ли ему предлложенные картинки разобраться с его проблемами? Хотя он уже давненько не появляется в теме. Наверное, утомили эти бесплодные дискуссии.

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

Прошу прощения, но я не в курсе, какое такое "все" шло и куда оно пришло в результате. Если достигнуты результаты, позволяющие облегчить труд разработчика и улучшить качество проектов, я бы с удовольствием с ними ознакомился вместо предложенных диаграмм.
Такие компании, как IBM, финансируют идеи, дающие реальную отдачу. Хотел бы я поглядеть на Буча, который вместо Rational Rose выдал бы набор треугольников и девиз дальнейшего повышения производительности труда.

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

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

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

Для меня это новость. Занимаясь системами автоматизированного проектирования микроэлектронной аппаратуры, я старался отслеживать все, связанное с экспертными системами, представлениями знаний, системами логических выводов и пр. Однако не видел единодушия по поводу единой формы представления данных, да и "математические" типы данных для меня загадка. Либо в этой области за последние 3-4 года произошел гигантский скачок и я безнадежно отстал, либо это из той же области, что и предыдущие треугольники.

Самый тяжелый момент в понимании, это стрелка, на 5 рисунке, от одной диаграммы к другой.

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

Наверное судя по картинке №5. С 1970 появилась возможность оперировать с математическими типами данных.  Насильно никто прогрессом пользоваться не заставит. Я сейчас, в 2005 году, наблюдаю примеры, когда под IBM PC люди пишут на АСМе.

Какие такие "математические" типы? Интегралы, множества, группы, ...? Что такое произошло в 1970 с типами? С точки зрения архитектуры машины - ничего, те же биты, слова, числа с плавающей точкой... С точки зрения языков программирования - тоже ничего особенного. Структурное программирование, структуры (или "неоднородные массивы", как их еще называли). Пожалуй, все. Причем тут математика?

Художник с оборудованием и софтом семидесятых не работал, а книжки читал. По тому что как минимум на свет появился в 80-х.

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

Почему такая тяга переврать написанное. Если проблема только в одной фразе, то ее можно и заменить. В скобка обычно пишут примерытого о чем говорят, ключевым терминами сздесь являются: язык моделирования и язык вычислительной среды Естественный язык вполне может быть языком моделирования, так же как и SQL и CASE могут быть языками вычислительной среды. Еще там в конце стоят три точки. Понятие вычислетельная среда, это не только IBM PC, это любое программируемое вычислительное устройство. В идеале, отвесающее принципам фон Неймана.

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

Да, а в коболе не было структур? Вполне возможно, я и ошибаюсь, с коболом 59 я действительно не работал, работал только с VisualAge Cobol, но как миниум два источника говорят, о том, что структуры все таки в коболе были.
http://objectz.com/pp/part2.asp
http://schools.keldysh.ru/sch444/MUSEUM/LANR/cobol.htm

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

[Igel]

Может, конечно, я излишне придирчив. Хорошо бы спросить у самого Igel'а, помогли ли ему предлложенные картинки разобраться с его проблемами? Хотя он уже давненько не появляется в теме. Наверное, утомили эти бесплодные дискуссии.

Если честно, то ДА, немного утомили. Я конечно понимаю, вам интересно, но хотелось-бы побольше практики.
Не появлялся, потому, что немного не до ответов было, да и сейчас, 10 мин. на все про все...

По теме. Почитал я книжку А. Коберн "Современные методы описания функциональных требований к системам". УМЛ там не разбирается, а приводятся примеры в плане базовой идеи книги. Основа это варианты использования, которые используются для описания всех процессов.
Для себя я определил сферу применения вариантов использования. Но это только анализ, на базе которого достигается взаимопонимание Заказчиков и Разработчиков и составляется некая модель  работы и взаимодействия системы.
Это почти то, что нужно, но я понимаю, что это только часть. Тут говорили про диаграммы, если память не изменяет, говорил Альф, хотелось-бы понять что оно и какие методики составления, и на основании чего составляются?

Время...

[Alf]

Если честно, то ДА, немного утомили. Я конечно понимаю, вам интересно, но хотелось-бы побольше практики.

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

Давай возвращаться к делу, тема очень интересная.

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

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

[Igel]

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

Задача? Хм-м, попробую с моей косноязыкостью.

[Igel]

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

Дальше.
Система должна обеспечивать решение задачи создания ТП для разных типов: (мехобработка, сборка, сварка, термохим. обработка, заготовка). Необходимо исследовать общие направления проектирования ТП разных видов (создать модели). Определить общее, определить различие и в идеале, создать ЕДИНУЮ модель проектирования ТП.
Технология содержит как графическую, так и текстовую(справочную) информацию.
Причем существующая практика такая:
- технология мехобработки это тексты(больше стандартные) плюс векторная графика, выполненная в АвтоКАД.
- сборочная технология тексты (произвольные) плюс графика 90% растровая (сканированные или нарисованные изображения) графика.

Вот в крадце... Что еще? Что-то в голову не лезет.

[Alf]

Вот уже потихоньку начинает прорисовываться функциональная модель.

Определились с основной функцией: "Получить техпроцесс изготовления детали".

В модели IDEF0 каждая функция - это черный ящик с определенными входами-выходами. Точнее, ее интерфейс определяется как ICOM (Input, Control, Output, Mechanism).

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

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

Control - стрелка, входящая сверху. Это управление функцией - стандарты отрасли и предприятия, графики выполнения работ и пр.

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

Mechanism - стрелка, входящая снизу. Это те ресурсы, которые используются при выполнении функции (оборудование,людские ресурсы).

Простейший пример. Бизнес-функция - изготовление вала на токарном станке.
Input: заготовка детали.
Control: чертеж детали, наряд на выполнение работы, стандарты (чистота поверхности и т.п.).
Output: обработанная деталь, брак.
Mechanism: токарный станок, комплект резцов, токарь 5-го разряда.

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

1. Что мы имеем на входе функции? (информация, непосредственно необходимая для разработки техпроцесса).
2. Чем управляется разработка техпроцесса? (стандарты предприятия, справочники, требования к оформлению документации, ...).
3. Что мы получим на выходе?
4. Какие ресурсы необходимы для выполнения функции? (технологи, автоматизированные рабочие места, серверы, принтеры, плоттеры, локальные сети, ...)

Ответы на эти вопросы лягут в основу бизнес-модели, которую мы далее будет детализировать.

[Alf]

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

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

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

[Igel]

Alf, я конечно попытаюсь надыбать AllFusion Process Modeler, но один-то я не буду работать над анализом. Придется подключать людей, а вот им нужно будет объяснять...

Дальше, что есть функция - "разработать техпроцес"? Это я бы сказал ЗАДАЧА. Хотя идея-то понятна, разложить задачу на состовляющие по уровням и приоритетам, как варианты использования.

[Alf]

Alf, я конечно попытаюсь надыбать AllFusion Process Modeler, но один-то я не буду работать над анализом. Придется подключать людей, а вот им нужно будет объяснять...

Я думаю, что всем объяснять тонкости работы с AllFusion не обязательно, хотя и не повредит, конечно. У себя, например, я обычно делаю так: короткое совещание, где я получаю ответы на свои вопросы, потом делаю эскиз в AllFusion, затем обсуждаем его с коллегами и заказчиком, вносим изменения - и так несколько раз до тех пор, пока все не станут довольны. Так что достаточно научиться самому или, если некогда, поручить кому-нибудь из подчиненных потолковее. А читать готовую диаграмму проще, она практически на интуитивном уровне понятна.

Дальше, что есть функция - "разработать техпроцес"? Это я бы сказал ЗАДАЧА. Хотя идея-то понятна, разложить задачу на состовляющие по уровням и приоритетам, как варианты использования.

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

Например: функция - изготовить редуктор. Подфункции: изготовить корпус, изготовить шестерни, собрать редуктор.
Дальше анализ: функция - изготовить корпус. Подфункции: отлить корпус, отфрезеровать, сверлить отверстия, нарезать резьбу... И так далее.

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

Когда ты ответишь на эти вопросы, я смогу сделать эскиз диаграммы IDEF0 и покажу этот процесс уже на реальном примере.

[Igel]

У себя, например, я обычно делаю так: короткое совещание, где я получаю ответы на свои вопросы, потом делаю эскиз в AllFusion, затем обсуждаем его с коллегами и заказчиком, вносим изменения - и так несколько раз до тех пор, пока все не станут довольны. Так что достаточно научиться самому или, если некогда, поручить кому-нибудь из подчиненных потолковее. А читать готовую диаграмму проще, она практически на интуитивном уровне понятна.

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

Теперь я задаю следующий вопрос: что нужно сделать, чтобы разработать техпроцесс? Какие основные работы предстоит выполнить?

Ладно, отвечу на эти вопросы, только это уже немало...

[LEON]

Igel, Это не диаграммы UML это диаграммы IDEF.

Вот здесь вот лежит неплохое руководство по IDEF, для твоей задачи, скорее всего понядобятся диаграммы IDEF0 и IDEF3.
http://www.cfin.ru/vernikov/idef/

А вот здесь лежат рисунки, как это все выглядит вживую, там все действительно интуитивно понятно.
http://ooad.asf.ru/standarts/idef/sadt/sadt113.shtml

Вот здесь более полное руководство, там все очень подробно, но книжка довольно большая, потребуется время, что бы ее прочитать
http://ooad.asf.ru/standarts/idef/sadt/index.shtml

[Alf]

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

Igel, у меня для тебя две новости: хорошая и плохая.

Сначала плохая: диаграммы UML и впрямь интуитивно понятными не назовешь. Для работы с ними нужен некоторый навык.

А теперь хорошая: в данный момент нам до UML - как до Рио-де-Жанейро на четвереньках 

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

Ладно, отвечу на эти вопросы, только это уже немало... 

Это - немало??? 

Да вопросы только начались, это лишь цветочки. 

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

[Dimka]

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

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

[Alf]

Во избежание дальнейших недоразумений:

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

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

[Igel]

Отвечу Димке, по поводу T-Flex. Конечно можно бы изучить существующие подходы и даже нужно, но это все упирается в денежку, причем немалую. Я сомневаюсь, что в сколь нибудь приемлимые сроки ты сможешь детально изучить возможности T-Flex, тем более если не полностью представляешь круг задач. А обучение это время и деньги. Если самому приобретать, то только кусочек можно и изучить, потому-что такие системы, это не просто купить коробочку с диском.
З.Ы. И в основном системы подобные T-Flex ориентированы не на наши производства, где ограниченное использование станков с ЧПУ. А они как правило и выдают программы для станков с ЧПУ, что и называется технология. Хотя у данного производителя ПО появилась Технологическая примочка(программа), которая и позволяет разрабатывать технологии по Российским ГОСТ-ам. Но ...

[Dimka]

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

Пример с редуктором, значит, был примером использования IDEF0, а не к анализу задачи относящийся. Хорошо, не понял сразу.

Про техпроцесс расскажу, как я его понимаю (из наблюдений за работой КБ и ТО и их взаимодействия). Упрощённо говоря:
1) конструктор создаёт чертёж какой-нибудь детали или изделия, помимо собственно чертежа, естественно, проводятся расчёты прочности и т.п., подбираются материалы
2) чертёж поступает к технологу, который с одной стороны анализирует условия эксплутации детали, с другой чертёж и разрабатывает технологию: процесс изготовления из заготовки нужной детали, сборки из деталей изделия и т.п.
3) Самый процесс изготовления является комбинацией атомарных действий: фрезеровки, сверления, сварки, покраски, прессования и т.п. У технолога есть нормативы, известен перечень этих атомарных действий, известны доступные материалы, рассчитывается стоимость изготовления. Задача оптимизации технологии: выполнить работу в кратчайшие сроки с наименьшей стоимостью. Т.е. техпроцесс можно представить деревом процессов разной степени сложности (как пример с редуктором).
4) В процессе разработки технологии технолог общается с конструктором на предмет замены материалов, изменения конструкции для упрощения изготовления и т.р.. Я видел такие сцены, что прибегает технолог в мыле к конструктору и начинает кричать: "Что ты тут понарисовал? Как я тебе эту загогулину высверливать буду? У меня нет S-образного сверла. А покрашу как? В эту щель головка пульверизатора не влезет" и т.п.

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

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

Это, так сказать, программа-максимум. Хорошо бы описать имеющиеся активы (какие существуют системы, что они позволяют делать).

[Igel]

Димка, отлично расписал все, почему у меня так не получается?
Но это все мне ясно. Поверхностная идея такая как ты описал, и так ее именно в институтах и пр. преподают. Только есть несколько жизненных уточнений, но их в концепцию и положим.
На вскидку несколько немаловажных деталей:
- Все данные по технологии должны быть доступны для системы планировния производства.
- На этапе разработки может возникнуть несколько вариантов технологии
- Инструмент на всех этапах разработки технологии необходимо подбирать, заказывать покупку, изготовление.
- С конструктором связи 99% не будет, только личное общение, т.к. другое предприятие.
Хотя это уже детали...

В общем все верно! Димка, объявляю благодарность!
По большому пока не готов добавить что-либо. Существует море ньюансов, но это на потом, как ты говорил, ты не технолог!

[Dimka]

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

Про конструкторов - сочувствую вашим технологам .

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

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

Например, пока ОПП, работающий "дедовским" способом готовит перевод производства на новую технологию, автоматизированный ТО (технологический отдел) подготавливает ещё более новую технологию, наиболее соответствующую текущей конъюнктуре рынка и состоянию смежных предприятий (потребителей и поставщиков). Т.е. ОПП будет тормозом всего процесса. А после подтягивания ОПП до уровня, тормозом станет производство, которое, как я понимаю, у вас ещё во многом ручное, коль даже станки с ЧПУ (про ГАПы уж не будем вспоминать) не распространены.

Ещё одна функция ОПП, которая мне известна, - планирование исполнения заказов, если у вас есть "сквозное" понятие заказа от продавцов через КБ, производство до склада и транспортировки. Но я очень надеюсь, что это не та часть взаимодействия, которую вам нужно создать, иначе см. ниже лирическое отступление.

Небольшое лирическое отступление, на всякий случай, так сказать ..

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

[Dimka]

Но это все мне ясно.

Одной из главных задач аналитика как раз и является та, чтобы словами, моделями, диаграммами - на каком-либо языке выразить то, что кому-то (ему в частности) ясно. Из сферы "подсознательного" неформального понимания (чутья) перевести в сферу систематизированного, чётко сформулированного, "проговоренного" понимания, и, более того, передать это понимание другим. И это прояснение понимания до способности передать другим образует новое знание - продукт аналитика. Иначе получается вроде собаки: всё понимает, а сказать не может

[Olegator]

Здравствуйте.
Вопрос по статье "Прецеденты в спецификации программ". Есть ли уже готовые проекты, чтобы посмотреть как это делается. Или так, чтобы уже по готовому проекту с некоторыми переделками начать программировать.

[Alf]

У меня, к сожалению, сей момент под рукой нет.

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

Как пример могу показать одну из диаграмм прецедентов из книги Дуга Розенберга и Кендалла Скотта "Применение объектного моделирования с использованием UML и анализ прецедентов (на примере разработки книжного Internet-магазина)".

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

[Olegator]

1. Это как надо читать? Объясни пожалуйста как эту диаграмму надо читать на примере доставки заказа.
   Как я понял прецедент "Доставить заказ" нужен для всех 3-х акторов. Вот только со стрелками я не разобрался.
2. Что за книга и где её взять.

[Alf]

Это пример диаграммы прецедентов, пожалуй, самой простой из диаграмм UML.

Эта диаграмма используется для решения двух задач:
1. Определить, что делает программа.
2. Определить, кто пользуется программой.

На диаграмме употреблены 3 вида значков. Человечки - это актеры, т.е. внешние по отношению к программе сущности (чаще всего это пользователи, но бывают и другие варианты). Эллипсы - собственно прецеденты, т.е. функции программы. Стрелки указывают на то, что данный актер участвует в данном прецеденте.

Иногда активирует прецедент один актер, а результат прецедента получает другой. Как раз этот случай отражен на прецеденте "Доставить заказ", где Упаковщик производит свою работу, а результат достается Участку Доставки. Затем наступает черед Доставщика.

Вот как в книге расписывается прецедент Обработать Готовый к Доставке Заказ:

Приемщик проверяет, что каждой Строке Заказа, присутствующей в Заказе на Покупку, соответствует физический товар. Приемщик считывает штрих-коды с упаковочного листа. Система изменяет состояние заказа на "выполнен" и обновляет количество каждой книги. Приемщик передает Книги Учетчику.

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

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

Книгу я не так давно заказывал в "Озоне". Если хочешь себе такую же, советую поторопиться, потому что подобные книги выпускаются почему-то мизерными тиражами - 2-3 тысячи, рискуешь не успеть.

[Olegator]

Посоветуй какие-нибудь книги по проектированию.

[Alf]

Вот что у меня перед глазами на книжной полке.

Теория:
1. Дуг Розенберг, Кендал Скотт. Применение объектного моделирования с использованием UML и прецедентов.
2. Кендал Скотт. Унифицированный процесс.
3. Кендал Скотт. UML.
4. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML. Руководство пользователя.
5. Джозеф Шмуллер. Освой самостоятельно UML за 24 часа.

Практика:
С. Трофимов. Rational XDE для Visual Studio.NET.
Книга написана довольно небрежно, полная даже грамматических ошибок, но других на эту тему у меня все равно нет.

Эти книги не о UML, однако тоже весьма важны для системного архитектора:
1. С. Маклаков. Моделирование бизнес-процессов с AllFusion Process Modeler.
2. С. Маклаков. Создание информационных систем с AllFusion Modeling Suite.
3. В. Дубейковский. Практика функционального моделирования с AllFusion Process Modeler.
Первые две книги хороши, третья - не очень, ибо полна ошибок. Порой отчетливо видно, что автор просто переводил фирменную документацию, особо не вникая в предмет, поскольку зачастую английские слова имеют несколько значений, и выбиралось не самое подходящее. Так что при чтении порой нужно в уме переводить фразы обратно с русского на английский дословно, чтобы понять, что это значило на самом деле. Например, фраза "bridging top-down theory with bottom-up implementation" переведена как "соединение вершин теории с основами выполнения". Явная чушь, поскольку на самом деле речь очевидно идет о сочетании проектирования "сверху-вниз" с реализацией "снизу-вверх", давно известная программистам техника. Хотя в целом материал добротный, даже горе-переводчик не смог его испортить полностью. однако новичка подобные перлы, которые там на каждом шагу, вполне могут сбить с толку.

Почти все эти книги я покупал в "Озоне", т.к. тиражи очень маленькие, в розничной продаже поймать трудно. Погляди, может, не все тиражи распроданы.

[Hooter]

Вот что у меня перед глазами на книжной полке.

А как же "Объектно-ориентированный анализ и проектирование (с примерами приложений на C++)" Гради Буча?
Имхо, эту книгу нужно одной из первых читать на эту тему.

[Alf]

А как же "Объектно-ориентированный анализ и проектирование (с примерами приложений на C++)" Гради Буча?
Имхо, эту книгу нужно одной из первых читать на эту тему.

Эту книгу нужно было читать одной из первых на эту тему в свое время. Увы, книга давно нуждается в пересмотре, поскольку со времени ее написания прошли годы, и ООП шагнуло далеко вперед (а тем более ООА).

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

[Olegator]

А как же "Объектно-ориентированный анализ и проектирование (с примерами приложений на C++)" Гради Буча?
Имхо, эту книгу нужно одной из первых читать на эту тему.

Эту книгу нужно было читать одной из первых на эту тему в свое время. Увы, книга давно нуждается в пересмотре, поскольку со времени ее написания прошли годы, и ООП шагнуло далеко вперед (а тем более ООА).

А как на счёт вот этих книг:
      "(C++) Как программировать на C++", Дейтел Х., Дейтел П
      "Объектно-ориентированное программирование" Т.Бадд
Эти книги тоже устарели? Может все новые книги написаны так что без прочтения старых не разберёшся?
Есть ли новые книги по ООП от начала до конца?