[GenaSPB 11]

Есть проект - обычное win32 mfc, dialog based. Отображает некий техпроцесс - используются own draw контролы, часть обмена с компортом...

СОбственно, заказчик захотел блок-схему алгоритма. Есть некоторая растеряность (кто не знает - в проекте куча файлов, обеспечивающих "игру по правилам" применённого фреймворка, собственно отображалкпа - это процентов десять от объёма текст).

Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений?

ps: c MFC начал работать ещё в 1995-м году. Опыт работы программистом более 25 лет.

[AHTOXA 18]

[Ожидание события] <--> [обработка события] :)

"Обработку" можно конкретизировать, типа "нажатие кнопки ВЫХОД", приход пакета из последовательного порта...

 

[=AK= 18]

Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений?

 

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

 

[V_G 11]

Я бы сделал блок-схему с тучей входов (на каждое событие). Зато очень легко на листы разбивать. Отдельно - блок-схема программы приема и разбора принятых посылок (она у меня в отдельном процессе, и после проверки целостности посылки рассылает сообщения специализированным окнам для дальнейшей обработки)

[Andrew2000 0]

Как может выглядеть "блок-схема алгоритма" таких событийно-управляемых приложений?

UML - Unified Modeling Language

В UML используются следующие виды диаграмм:

- Диаграмма классов

- Диаграмма компонентов (файлы, библиотеки, модули)

- Диаграмма деятельности (отдаленным аналогом являются схемы алгоритмов по ГОСТ 19.701-90)

- ... и еще много чего...

 

рисовалки: Dia, MS Visio, NetBeans+UML plugin, Umbrello (Linux), ....

[GenaSPB 11]

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 11]

Такие функции и обработки системных событий я бы нарисовал одним большим квадратиком с надписью типа "Системные функции, автоматически генерируемые средой программирования". Иначе придется рисовать блок-схему Windows, MFC, и не дай бог, Net Framework. Заказчик обязан хотеть блок-схему ВАШЕГО алгоритма, а не блок-схему алгоритма Windows. За последней пусть обращается в Микрософт, ему нарисуют...

[Flexz 0]

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

Еще у нас последнее время более популярно словесное описание алгоритмов работы: режимы работы, списки возможных воздействий, реакции системы, результаты - эдакое ТЗ преросток. Такое легко составлять вместе с заказчиком еще на начальных этапах работы и поддерживать в разы проще чем схемы.

 

PS а схемы алгоритмов заказчику вообще зачем? Часом не просто в архив положить? Если так, то все решается банальной отпиской - нарисовать что-то близкое к реальности и по госту, все довольны.

[GenaSPB 11]

Теперь понятно, отчего горе? Именно _весь_ _код_ _должен_ _быть_ _документированы_.

Блок-схемой алгоритма...

Скорее всего, в архив. Как образец показали алгоритм embedded программы, работающей на PIC (байт 800 кода как результат трансляции "С"). Вот там рисунок алгоритма есть, есть обширное словесное описание.

А то, что в виндовой части 90% это обслуживающая часть, не имеющая отношения к работе программы...

Программа решает одну или несколько задач связанных с неким тех-процессом, так?

Один контрол самописный и работа с com-портом + конфигурационный диалог без самодеятельности.

 

Ну это так... вопль с тоски.

Спасибо за помощь.

 

Конкретнее - кто-нибудь документировал служебные функции MFC?

Изменено 9 августа, 2011 пользователем Genadi Zawidowski

[V_G 11]

Конкретнее - кто-нибудь документировал служебные функции MFC?

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

В смысле, если хороший юрист пороется, может, он и не найдет в этом криминала. Но перед заказчиком отстаивать именно эту версию.

Изменено 9 августа, 2011 пользователем V_G

[GenaSPB 11]

PS а схемы алгоритмов заказчику вообще зачем? Часом не просто в архив положить? Если так, то все решается банальной отпиской - нарисовать что-то близкое к реальности и по госту, все довольны.

Не нулевое время требуется. Что интересно, это оказалось единственным перпятствием к завершению работ. Так же выяснилось, что _все_ делают полные алгоритмы, один я такой... Вот и взвешиваю - не послать ли.

Заказчик обладает некоторым опытом программирования.

Изменено 9 августа, 2011 пользователем Genadi Zawidowski