OSDev

Yoda, думаю, что в серьёзных фирмах без инструментов графического документирования даже кофе не садятся пить. Может даже этот инструмент - UML, может что-то ещё (какое либо подмножество этого языка). И согласен, что не всё можно формализовать, а некоторые вопросы можно только в вербальной форме раскрыть, но не все ведь?! - Некоторые лучше в графическом виде. В ЮМЛе можешь как исодники с коментариями привести, так и более формально их обобщить: Это - планировщик. Он находится вот в этой части системы. Работает с такими-то структурами данных. Вот так представлена его работа в виде автомата. А это фрагмент его кода.
По-моему - это лучший способ решить терминологические недопониманания, да, и вообще огромный плюс ко всему. Нужно тебе системный модуль переписать (или мне твой), глянул на схему и все тонкости работы видны. А переписать/доработать код - незначительная формальность, при этом.. Главное, что логика будет видна, чего код не даёт (даже с коментариями).
ПыСы. Прошу прошение за много букв - пишу быстро и с телефона.

Во всём цивилизованном мире уже давно взяли за правило, что документация проекта порой важнее самого проекта. Это видно из истории того же OMG. Всякие крутые компании типа Сан, Кэннон, Мелкомягкие, Американ Эирлайн и т.д. (800 компаний) столкнулись с проблемой нестардантов ПО, и основали тот самый ОЭМДЖИ. Главная цель - придумать универсальный инструмент стандартизованного представления ПО, начиная с планирования проектирования, и заканчивая выведением ПО из эксплуатации. Т.е. инструмент сопровождения на всём жизненном этапе ПО. Это инструмент и есть UML (+бонусы от омг). Нам, простым форумным осдеверам, думаю, позволит не плодить сущностей (осей), а брать и дорабатывать готовые оси ещё проще, чем выдумывать с нуля новые. Да и проекты, глядишь развиваться начнут, когда в новой оси за вечер разобраться можно будет. Кто как думает?

Думаю ваш UML не одна серьёзная фирма не использует настолько. Да и вообще думаю полно серьёзных фирм которые UML не используют.


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

Мечтать не вредно. Вот только сделать чтобы было понятно очень нелегко.

Павиа, хватит флудить. Если есть что дополнить или поправить - пиши по теме. А если не знаешь до чего до.....ся - ступай лесом в другие темы.

Я не сторонник UML и CASE систем подобного класса. Прежде всего потому, что на мой взгляд, эти подходы предназначены для решения других задач. Они хорошо подходят для бизнес-задач, таких как управление базами данных, организация безбумажного учёта и вообще для работы с потоками данных. Но в случае ОС намного чаще приходится решать другие задачи, которые вписываются в UML-схемы с большой натяжкой (это ещё ладно бы) и (самое главное) их решение в рамках CASE оказывается неэффективным. Между бизнес схемами и ОС-девелопментом есть серьёзные идеологические противоречия.
1. В бизнес-задачах один из доминирующих факторов - скорость её решения. "Если ко вчерашнему мне не сделаете, сорвётся сделка". CASE-системы действительно преуспели в скорости разработки. Но в ОС-девелопменте же это совсем не главное. Доминирующим фактором становится качество решения. А так, да, - можно за вечер нарисовать схему, которую утром покажешь на презентации, к обеду сгенеришь код, который будет ворочать мегабайтами данных, а всю оставшуюся неделю подчинённые будут набивать каркас интерфейсными функциями.
2. CASE-системы ориентированы на потоки данных, в то время, как ОС ориентирована на эффективные алгоритмы. Так, если я реализую алгоритм сжатия Lempel-Ziv в визуальной системе (хотя мне ОЧЕНЬ сложно себе это представить), то при сжатии даже мелкого файла мне придётся заваривать себе кофе. А ведь ОС буквально на 99% состоит из подобных задач.
Есть ещё другие факторы. Так, на одно из первых мест в любом деле я ставлю фактор личности. За свой опыт я всё больше в этом убеждаюсь. Визуальное программирование на практике не спасает от непонятности. Есть люди, которые запутают даже самую простую диаграмму.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Решил немного погуглить. Начал с простого: "проектирование программного обеспечения". Гугл подкинул двух молодцов: Первая ссылка - Википедия, ссылка ниже - Хабр. Открываю рядом два окна: слева Осдев с постом Ёды, справа - Хабра (http://habrahabr.ru/blogs/development/74330/). Читаю по абзацам с некоторыми пропусками:


Далее..


Ещё разочек..


Заключительный пассаж..

Кода. Антракт.

Постараюсь быть последовательным. Итак, что же такое проектирование?

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

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

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

Это неполный список диаграмм; достаточный для абстрактного представления структуры системы, но не содержащий достаточное количество информации для реализации системы. Полный список определён стандартом унифицированного языка моделирования (UML). -Это такой объём информации, который достаточен для кодогенерации системы, при заданных требованиях (Пункт 2 Жизненного цикла ПО).
Хотя, для проектирования UML необязателен, и легко может быть заменён любым языком моделирования, покрывающим предметную область, но:

..и принимается стандартом моделирования среди более 800 компаний, среди которых: Acer, Cisco, HP, American Airlines, Hitachi, IBM, Siemens, Microsoft Sun, Sybase, Boeing, EDS, Ericsson, Netscape, Nokia, Ford Motor, Oracle и ряд других.

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

Mr.McD. доблестно нокаутировал бесславного Йоду ударом под дых :)))))
Отсылки просто замечательные. Я такие перлы буду на стенку в отделе для подчинённых развешивать


Всё правильно! Я же именно так и говорю! Вечером диаграмма, утром презентация, а всё неделю вкалывает толпа кодеров. Ну или месяц, если в твоей диаграмме чёрт ногу сломит (это к слову о факторе личности). Одним словом, "работать, негры!!!" ))))


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


То есть как это, без личного опыта??? Погоди, не понял... ща, дай разобраться......
Это по Козьме Пруткову, что ли? Если на клетке слона прочтёшь надпись "буйвол", не верь глазам своим?
Ну ладно, раз авторитетный дядя написал "буйвол", так тому и быть. Тогда мне придётся устраниться от обсуждения, т.к., к сожалению, уже испорчен личным опытом, а здесь приветствуются только чистые, абстрактные теоретики.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

1 Какое проектирование с презинтациями? Здесь все в одиночку работают() - каждый над своим неповторимым самым-самым проектом ос. вся документация и проектирование (в голове) ...
"если единственный инструмент молоток - то любая задача сводится к поиску гвоздя"


2 Эти хорошие технологии - мешают в некотором смысле свободе манёвра. Другими словами если пользоваться общепринятыми инструментами - то получится тоже самое на выходе.