powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Дизайн приложения. Обсуждение темлайтов.
9 сообщений из 9, страница 1 из 1
Дизайн приложения. Обсуждение темлайтов.
    #33585225
McLuad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем Привет.
Решил поднять следующую тему:
Скажем так, уже достаточно давно работаю архитектором, в нескольких проектах для разных клиентов. Вопрос в оформлении дизайна приложения. Каждый раз это было что-то разное. Но обычно, в результате получается MS Word документ, за исключением того, когда используется CASE средсво, в этом случае на выходе я даю бинарник от соответсвующего тула вместе в Architecture Document или вместо него.
Дизайн также делается на каждый модуль. Например, Cache. Logging, File management, Data Access и так далее.
Мне в принципе стало интересно, как этот процесс поставлен у других разработчиков. В большей степени, интересует опыт дизайнеров, работающих в оффшорных проетах.
Поэтому предлагаю обсудить следующие вопросы:
1. Темплате дизайна одного модуля.
2. Темплате дизайна целого приложения
3. Компоненты, входящие в дизайн.
4. Формат написания Use-Case, sequence diagram, Component Diagram (другие не использую), другие диаграммы.
5. Формат описания requirements
6. Типы requirements: Functional/None Functional (Business, Security, Performance, User Interface …).
7. Другие вопросы.

Если наладится диалог, готов показать дизаин своих проектов.
Для затравки предлагаю темплате для пункта 1.
В качестве примера рассмотрен модуль Logging, только дезайн, requirements идут отдельно.

Основные моменты
1 OVERVIEW
2 ABBREVIATIONS AND DEFINITIONS
3. DIAGRAMS AND MODELS
4 ADDITIONAL NOTES4
5 CLASS INTERFACES
6. SAMPLES (AND HOW TO’S)

LOGGING FUNCTIONAL SPECIFICATION 1
1 OVERVIEW 4
2 ABBREVIATIONS AND DEFINITIONS 4
3 ADDITIONAL NOTES 4
3.1 PERIODICAL DATA CLEAN-UP. 4
3.2 REFRESH CONFIGURATION 4
4 DIAGRAMS AND MODELS 5
4.1 CONCEPTUAL DIAGRAM 5
4.2 COMPONENT MODEL 6
4.3 DATA MODEL 7
4.4 LOG SERVICE CLASS DIAGRAM 7
4.5 LOGGING CLASS DIAGRAM 8
4.6 LOG SERVICE SEQUENCE DIAGRAM 9
4.7 LOGGING SEQUENCE DIAGRAM 10
5 CLASS INTERFACES 11
5.1 LOGWRITER CLASS 11
5.1.1 Description 11
5.1.2 Definition 11
5.2 LOGDATA CLASS 11
5.2.1 Description 11
5.2.2 Definition 11
5.3 LOGGERLEVEL ENUMERATION 12
5.3.1 Description 12
5.3.2 Definition 12
6 SAMPLES (AND HOW TO’S) 12
6.1 SAMPLE CODE 13
6.1.1 Accessing the Logging module from external an application: 13
6.2 RELATED SAMPLE CONTENT 13
6.3 SET UP MSMQ CONFIGURATION. 13
6.3.1 Install “Message Queuing” windows component 13
6.3.2 Specify the queue name. 14
REVIEWED AND APPROVED 15
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33585352
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
The problems of automation facing to IT-experts, they different only at their superficial analysis. And actually - all of them are identical. And consequently the interface for all projects can be identical. Only it is necessary to present correctly a problem, i.e. a subject of automation. Do not find it for advertising, but I suggest to look clause "the Method of elementary objects" which underlies construction of a program complex the BAS .

As a result - the same bas.exe without any changes is applied to the decision absolutely different (at first sight) problems. And in the interface, only a few forms - input of operations, personal accounts, a window of the analysis of results, a window of listing of reports, and also windows for adjustment of corresponding modes.
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33585374
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Oh, entschuldigen Sie. Hat, daß Forum nicht englisch vergessen.

Die Aufgaben der Automation, die vor den IT-spezialisten kostet(steht), sie verschiedene nur bei ihrer oberflächlichen Analyse. Und wirklich sind - sie identisch. Und folglich kann(darf) das Interface für alle Projekte identisch sein. Nur muß man die Aufgabe, d.h. den Gegenstand(Fach) der Automation richtig vorstellen.

Halten Sie es für die Werbung nicht, aber ich biete an, den Artikel "die Methode der elementaren Objekte" anzuschauen, der die Konstruktion des Programmkomplexes den Baß bildet. Daraufhin wird - ein und selb bas.exe ohne jede Veränderungen für den Beschluß vollkommen verschiedene (auf den ersten Blick) der Aufgaben verwendet. Und im Interface, nur wenige der Formen - die Inbetriebnahme der Operationen, die Gesichtsrechnungen, das Fenster der Analyse der Ergebnisse, das Fenster des Ausdruckens der Berichte, sowie des Fensters für die Einregulierung der entsprechenden Regimes.
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33585381
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нет, вечером надо йти домой, а не сидеть за компьютером. Вечно что нибудь перепутаешь. Как это плохо, много знать. Последняя, третья попытка.

Задачи автоматизации, стоящие перед IT-специалистами, они разные только при их поверхностном анализе. А на самом деле – они все одинаковы. И поэтому интерфейс для всех проектов может быть одинаковым. Только надо правильно представить задачу, т.е. предмет автоматизации. Не сочтите это за рекламу, но предлагаю посмотреть статью «Метод элементарных объектов» , который лежит в основе построения программного комплекса БАС . В результате – один и тот же bas.exe без всяких изменений применяется для решения совершенно разных (на первый взгляд) задач.

А в интерфейсе, только несколько форм – ввод операций, лицевые счета, окно анализа результатов, окно распечатки отчетов, а также окна для настройки соответствующих режимов.
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33585583
М.Голованов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PVPЗадачи автоматизации, стоящие перед IT-специалистами, они разные только при их поверхностном анализе. А на самом деле – они все одинаковы.

А я-то думаю, чего это столько прораммистов расплодилось?... Дармоеды, однако....

На самом-то деле задачи одинаковы при поверхностном анализе. Еще они одинаковы в элементарных функциях. А все остальное, к сожалению, всегда уникально... если речь идет не о тиражирвоании, но вы ведь не о нем?...
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33585990
Фотография PVP
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
М.ГоловановА все остальное, к сожалению, всегда уникально... если речь идет не о тиражирвоании, но вы ведь не о нем?...Да нет, не о тиражировании. О разработке. Ну конечно, не всех абсолютно задач, а достаточно широкого класса - учетных и управленческих систем (вчера настроение было не достаточно серьезное, что бы ограничить область применения).

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

Далее фукции - взаимосвязь между параметрами операции, взаимосвязи между параметрами деталей.

То же самое можно сказать об отчетах, о справочниках. Все это одинаково. Отличие состоит в наборе и в названии параметров, а также в процедурах обработки их взаимосвязей.

Я не утверждаю, что все формы одинаковы. Я утверждаю, что все они построены по один и тем же принципам. А значит программное обеспечение для их реализации - может быть построено одно, общее.
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33586896
gggg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PVPЯ не утверждаю, что все формы одинаковы. Я утверждаю, что все они построены по один и тем же принципам. А значит программное обеспечение для их реализации - может быть построено одно, общее.

Скажем с использованием одних и тех же команд Ассемблера ?
Что есть кирпич в Вашем доме ?
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33587010
McLuad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ребята, что-то вы совсем не то написали, что я предлагал обсудить.
К примеру, что не флудить, предлагаю обсудить способ описания requiements.
...
Рейтинг: 0 / 0
Дизайн приложения. Обсуждение темлайтов.
    #33593470
Фотография byur
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
McLuadВсем Привет.
Решил поднять следующую тему:
Скажем так, уже достаточно давно работаю архитектором, в нескольких проектах для разных клиентов. Вопрос в оформлении дизайна приложения. Каждый раз это было что-то разное. Но обычно, в результате получается MS Word документ, за исключением того, когда используется CASE средсво, в этом случае на выходе я даю бинарник от соответсвующего тула вместе в Architecture Document или вместо него.
Дизайн также делается на каждый модуль. Например, Cache. Logging, File management, Data Access и так далее.
Мне в принципе стало интересно, как этот процесс поставлен у других разработчиков. В большей степени, интересует опыт дизайнеров, работающих в оффшорных проетах.
Поэтому предлагаю обсудить следующие вопросы:
1. Темплате дизайна одного модуля.
2. Темплате дизайна целого приложения
3. Компоненты, входящие в дизайн.
4. Формат написания Use-Case, sequence diagram, Component Diagram (другие не использую), другие диаграммы.
5. Формат описания requirements
6. Типы requirements: Functional/None Functional (Business, Security, Performance, User Interface …).
7. Другие вопросы.

Если наладится диалог, готов показать дизаин своих проектов.
Для затравки предлагаю темплате для пункта 1.
В качестве примера рассмотрен модуль Logging, только дезайн, requirements идут отдельно.


Описание архитектуры или дизайна ПО обычно делается в соотвествии с некоторым стандартом. Обсуждение произвольной формы очень сложно вести... Если речь идет конкретно об описании дизайна, то можно посмотреть на стандарт IEEE Std 1016-1998. IEEE Recommended Practice for
Software Design Descriptions. Там есть общий взгляд на то как должно быть предствлено описание дизайна системы, в т.ч. и в связи с требованиями к ПО. Существует аналогичный стандарт и для описания архитектуры IEEE Std 1471-2000 IEEE Recommended Practice for
Architectural Description of Software-Intensive Systems. Оба документа используют одинаковый подход -- использование понятия views для описания как архитекутры так и дизайна.
Несколько другой вопрос, как "впихнуть" туда UML :-) ... в частности, что касается архитектуры и ее описания -- то есть статья Крухтена про подход "4+1", который в частности лег и в основу RUP.

Да, и что вы хотели обсудить по поводу требований к ПО и их описания?
...
Рейтинг: 0 / 0
9 сообщений из 9, страница 1 из 1
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Дизайн приложения. Обсуждение темлайтов.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]