Comments 4
достаточно не велик ... и что не мало важно...
...
Внимательный читатель
Внимательный читатель ослеп.
Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).
Очень странная постановка задачи. Берётся язык, который можно хорошо использовать для описания (документирования) существующей системы, и его предлагается использовать для проектирования? Это же разные задачи! И должны использоваться разные языки.
Мой комментарий (по англ. comment) на статью - черезчур размыто, сложно и противоречиво.
Например в последнем абзаце (по англ. paragraph) описание технического решения и проектная документация видится как одно. И одно исходит из другого. Но в жизни это два разных мира.
А такой совет как этот - вообще вреден.
Отложите принятие решения об использовании технических инструментов на конец этапа проектирования.
Выбор технических инструментов играет огромную роль (по англ. rоle), каким будет вообще проект.
А такие истины как эта - непонятно о чём. Как коррелирует равномерное написание кода и его качество - не ясно.
проектирование позволяет более равномерно распределить объём работ связанных с написанием кода, тем самым повышая его качество.
Перед тем как продолжить чтение, рекомендуется ознакомиться с предыдущими статьями цикла
А ссылки где?
один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML
Говоря, по рабоче-крестьянски, рисуйте блок-схемы ваших будущих программ, и будет вам счастье.
Это, конечно, хорошо, но этого мало. На этих идеях даже собственный пет-проект не сделаешь. А ваша «Схема взаимодействия модулей» слишком абстракта, чтобы быть полезной. Все остальное, без демонстрации готовой программы, тоже, на любителя.
Я, вот, после реализации своего пет-проекта: «Новая компьютерная программа для запоминания иностранных слов и фраз» ( https://habr.com/ru/articles/848836/ ), мог бы, пожалуй, написать что-то более конструктивное. Но, сначала хочу сделать вторую версию этой программы, чтобы говорить о своих принципах проектирования программ более конкретно.
Однако пару слов могу сказать уже сейчас.
Очень удобен метод «итерационно-модульного» программирования. По данной программе у меня было 13 итераций и порядка 20 различных блок-схем. Последние рождались при мучительной боли, в процессе разработки непротиворечивой и эффектной программной логики. Разработкой бизнес-логики я занимался, для своей другой программы, на работе, но, сказать, что:
Бизнес-логика являет(ся?) самой стабильной частью разрабатываемого приложения, ведь для её автоматизации и создавалась.
это, значит, слегка слукавить. Теоретически, это как бы так, но, практически, верно, с точностью, до наоборот. При всей ее «стабильности» вариантов реализаций может быть бесконечно много, а неопределенности в их выборе – «выше крыши».
При этом, никакие новомодные концепции программирования мне не помогли от слова «совсем». Только, в абстрактном виде, ООП. Всё остальное – исключительно здравый смысл.
Что я планирую для своей второй версии обучающей программы?
Зафиксировать минимальный структурный шаблон для программ подобного типа. Это несколько классов, написанных на C++ / WTL, начальные, из которых – всегда постоянны, как дебюты в шахматах. Я имею в виду файл с модулем wWinMain() и класс приложения CApp.
Далее уже идут полуфиксированные классы, вроде CMainWindow и классы, с которыми работает класс главного окна.
Главная фишка – это вставка / удаление некоторого объекта и его данных в класс главного окна либо в его подклассы. Другими словами, легко вставил код и данные, реализующие некоторую заданную функциональность – легко удалил их, при необходимости.
Обеспечить независимость, друг от друга, вставляемых / удаляемых блоков кода и данных.
Каждая новая итерация проекта – это вставка некоторого самодостаточного блока кода и данных (если они могут выражаться через класс, то класса)
В каждой итерации проекта описывается добавляемый объект и, если было, изменения объектов прошлых итераций.
При этом, если мы напартачим в текущей итерации, то всегда можно откатиться на предыдущую, что меня не раз выручало.
Как-то так.
Для меня это вполне рабочая схема, в отличие от «сферических коней в вакууме», про которые тут так любят говорить.
Диаграмма классов (англ. Class diagram)