Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Блок-схема алгоритма (MFC application)
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Genadi Zawidowski
Есть проект - обычное win32 mfc, dialog based. Отображает некий техпроцесс - используются own draw контролы, часть обмена с компортом...
СОбственно, заказчик захотел блок-схему алгоритма. Есть некоторая растеряность (кто не знает - в проекте куча файлов, обеспечивающих "игру по правилам" применённого фреймворка, собственно отображалкпа - это процентов десять от объёма текст).
Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений?
ps: c MFC начал работать ещё в 1995-м году. Опыт работы программистом более 25 лет.
AHTOXA
[Ожидание события] <--> [обработка события] sm.gif
"Обработку" можно конкретизировать, типа "нажатие кнопки ВЫХОД", приход пакета из последовательного порта...
=AK=
Цитата(Genadi Zawidowski @ Aug 6 2011, 03:25) *
Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений?


Дракон-диаграмма

Нажмите для просмотра прикрепленного файла
V_G
Я бы сделал блок-схему с тучей входов (на каждое событие). Зато очень легко на листы разбивать. Отдельно - блок-схема программы приема и разбора принятых посылок (она у меня в отдельном процессе, и после проверки целостности посылки рассылает сообщения специализированным окнам для дальнейшей обработки)
Andrew2000
Цитата(Genadi Zawidowski @ Aug 5 2011, 21:55) *
Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений?

UML - Unified Modeling Language
В UML используются следующие виды диаграмм:
- Диаграмма классов
- Диаграмма компонентов (файлы, библиотеки, модули)
- Диаграмма деятельности (отдаленным аналогом являются схемы алгоритмов по ГОСТ 19.701-90)
- ... и еще много чего...

рисовалки: Dia, MS Visio, NetBeans+UML plugin, Umbrello (Linux), ....
Genadi Zawidowski
Цитата(Andrew2000 @ Aug 8 2011, 14:50) *
UML - Unified Modeling Language
...

Грустно то, что куча функций фреймворка, не несущих никакого смысла для понимания функционирования задачи, находятся в исходниках проекта.
И какой смысл описывать например такое:

Код
// The system calls this to obtain the cursor to display while the user drags
//  the minimized window.
HCURSOR CIndicdDlg::OnQueryDragIcon()
{
    return (HCURSOR) m_hIcon;
}


или такое:

Код
// If you add a minimize button to your dialog, you will need the code below
//  to draw the icon.  For MFC applications using the document/view model,
//  this is automatically done for you by the framework.

void CIndicdDlg::OnPaint()
{
    if (IsIconic())
    {
        CPaintDC dc(this); // device context for painting

        SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0);

        // Center icon in client rectangle
        int cxIcon = GetSystemMetrics(SM_CXICON);
        int cyIcon = GetSystemMetrics(SM_CYICON);
        CRect rect;
        GetClientRect(&rect);
        int x = (rect.Width() - cxIcon + 1) / 2;
        int y = (rect.Height() - cyIcon + 1) / 2;

        // Draw the icon
        dc.DrawIcon(x, y, m_hIcon);
    }
    else
    {
        CDialog::OnPaint();
    }
}
V_G
Такие функции и обработки системных событий я бы нарисовал одним большим квадратиком с надписью типа "Системные функции, автоматически генерируемые средой программирования". Иначе придется рисовать блок-схему Windows, MFC, и не дай бог, Net Framework. Заказчик обязан хотеть блок-схему ВАШЕГО алгоритма, а не блок-схему алгоритма Windows. За последней пусть обращается в Микрософт, ему нарисуют...
Flexz
Программа решает одну или несколько задач связанных с неким тех-процессом, так? Вот и нарисуйте алгоритмы решения этих задач. А делать схему алгоритма всей программы вместе с GUI дело неблагодарное, все равно в таком монстре черт ногу сломит.
Еще у нас последнее время более популярно словесное описание алгоритмов работы: режимы работы, списки возможных воздействий, реакции системы, результаты - эдакое ТЗ преросток. Такое легко составлять вместе с заказчиком еще на начальных этапах работы и поддерживать в разы проще чем схемы.

PS а схемы алгоритмов заказчику вообще зачем? Часом не просто в архив положить? Если так, то все решается банальной отпиской - нарисовать что-то близкое к реальности и по госту, все довольны.
Genadi Zawidowski
Теперь понятно, отчего горе? Именно _весь_ _код_ _должен_ _быть_ _документированы_.
Блок-схемой алгоритма...
Скорее всего, в архив. Как образец показали алгоритм embedded программы, работающей на PIC (байт 800 кода как результат трансляции "С"). Вот там рисунок алгоритма есть, есть обширное словесное описание.
А то, что в виндовой части 90% это обслуживающая часть, не имеющая отношения к работе программы...
Цитата
Программа решает одну или несколько задач связанных с неким тех-процессом, так?
Один контрол самописный и работа с com-портом + конфигурационный диалог без самодеятельности.

Ну это так... вопль с тоски.
Спасибо за помощь.

Конкретнее - кто-нибудь документировал служебные функции MFC?
V_G
Цитата(Genadi Zawidowski @ Aug 9 2011, 18:06) *
Конкретнее - кто-нибудь документировал служебные функции MFC?

Я бы подвел это под реверс-инжиниринг - действие, напрямую запрещенное лицензионным соглашением.
В смысле, если хороший юрист пороется, может, он и не найдет в этом криминала. Но перед заказчиком отстаивать именно эту версию.
Genadi Zawidowski
Цитата(Flexz @ Aug 9 2011, 10:28) *
PS а схемы алгоритмов заказчику вообще зачем? Часом не просто в архив положить? Если так, то все решается банальной отпиской - нарисовать что-то близкое к реальности и по госту, все довольны.

Не нулевое время требуется. Что интересно, это оказалось единственным перпятствием к завершению работ. Так же выяснилось, что _все_ делают полные алгоритмы, один я такой... Вот и взвешиваю - не послать ли.
Заказчик обладает некоторым опытом программирования.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.