OSDev

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

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

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



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

Ну, не столь категорично, конечно:)

Полностью согласен, но данная тема, всё же, создана для обсуждения проектирования новых систем. А гиганты пусть как хотят, так и делают (Хотя ЮМЛ поддерживается именно по их инициативе).

Всё зависит от того, где провести границу между общепринятым и полётом фантазии.
Из общепринятого ты, вероятно, пользуешься общепринятыми компиляторами в нативный код платформы (хотя мог бы написать свой), используешь общепринятые представления пользовательского интерфейса (хотя можно было бы ВООБЩЕ без интерфейса), притягиваешь общепринятые принципы к своей системе (многозадачность, вирт.память...). Почему не применять общепринятые стандарты моделирования и документации?
Что касается полёта фантазии: если пишешь систему для себя одного, да и уверен, что через 10 лет вспомнишь: "А почему я в этом месте сделал так, а не иначе?" - можно держать весь проект в голове. А попробуй написать систему так, чтобы в ней можно было разобраться за вечер, хоть соседу-программисту, хоть ребятам на форуме, хоть младшему брату.
//Убеждён, что ОСь должна писаться на ассемблере. Т.е. сама система должна отражать исключительно логику и функционал, а её реализация для конкретной платформы - дело кодинга, а не проектирования, со всеми преимуществами низкоуровневой оптимизации. Думаю, многие здесь согласятся. А что делать, когда объём исходников перевалит за 100.000 строк ассемблерного кода? Вот нужно мне будет, например, новый модуль в систему добавить, или потребовался перенос на новую платформу с сохранением прежнего функционала.. Как это сделать быстро и с минимальным количеством ошибок? - Не вижу способа лучше, чем изначально проектировать систему в виде отдельных компонентов (с чётко определёнными функционалами и интерфейсами). А когда система - наглядна, тогда несложно хоть новый компонент добавить, хоть на другой ассемблер всё перенести.. Да, и как сказал Yoda: "Производить отладку компонентов по-отдельности!":) Только для этого нужно изначально выбрать компонентный подход, а не "пилить на куски" уже рабочий монолит кода (проще написать заново). Собственно, в этом и вопрос: в каком формате представлять проект новой системы, чтобы его можно было вести как распределённо, так и с экономией макулатуры? Леса-то в стране не резиновые!;)

Вопрос, есть ли у вас хоть малейшее желание не то, что проектировать ось, а хотябы заняться созданием её в перспективе? Я не вижу его. Занимаются ли этим те люди, которые учавствуют в обсуждениях и считаются действительно специалистами в этой области, доказав это неоднократно как Pavia, Sii, Yoda, ... . Или вопроса её создания ни у кого не стоит?



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

О как!:)

Создание всяческих ОС тематика данного форума. Речь идёт же о том что создание надо начинать с проектирования. Разруха она в головах. Сложность кода может превысить все мыслимые пределы. Может возникнуть необходимость подключения другого разработчика вида у которого просто не работает телепатия. Отсюда необходимость проектирования и документирования.


Непонятно как практика проектирования и наличие опыта программирования оценивается и определяется количеством изученных языков. Вдруг вы на всех них ничего кроме "Hello World!" не писали?

Только без обид.

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

На самом деле люди, заявляющие, что не пользуются документацией при разработке - лукавят. Не обязательно пользоваться своей собственной документацией, если можно документацию позаимствовать. Посмотрите хотя бы на начинающие проекты. 90% пользуются руководствами типа блогов James Molloy, Lonesome, KIV и др. Есть книжки в конце-концов. То же самое и с заиствованием кода. Пока есть откуда взять готовый код, или есть с кем обсудить в интернете - есть более-менее быстрый прогресс. Когда приходится все писать с нуля, копать спецификации на предмет того, что еще никто популярно не описывал, наступает совершенно иная ситуация.

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

У меня сейчас текущие 2 типа проектов. 1-японцы. 2-американцы.

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

2. Американцы - из документации только требования на пользовательский интерфейс и документация на внутреннюю вебовую шину (out of date). Между требованиями на пользовательский интерфейс и другими частями системы связи никакой. Стиль проекта Agile. Время рассчитанное на разработку следующего релиза в существенной степени расходуется на фикс багов предыдущего релиза. Все вопросы обсуждаются в почте, количество редиректов, возникающих при решении того или иного вопроса - просто не прилично. Багов на проекте сотни и трудоемкость проекта просто не поддается в итоге нормальной оценке. Программисты увольняются - знания теряются...

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

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

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

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

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

Не стоит так уж сильно ругать Molloy и его предшественников. Все-таки с тех пор как они сделали свою работу прошло много лет. Тогда информации было меньше и систематизирована информация была хуже. Судя по цитируемости в интернете с мотивацией начинающих у Molloy-я все нормально Ошибки бывают у всех, тем более в у первопроходцев в OSDEV. Количество ошибок можно уменьшить, но чтобы избавиться от ошибок, есть лишь один способ - ничего не делать. Опять же, если бы все всё делали идеально, нам с вами нечего было бы уже делать. Всё бы уже было написано до нас