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

[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++", Дейтел Х., Дейтел П
      "Объектно-ориентированное программирование" Т.Бадд
Эти книги тоже устарели? Может все новые книги написаны так что без прочтения старых не разберёшся?
Есть ли новые книги по ООП от начала до конца?