|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
Всем Привет. Решил поднять следующую тему: Скажем так, уже достаточно давно работаю архитектором, в нескольких проектах для разных клиентов. Вопрос в оформлении дизайна приложения. Каждый раз это было что-то разное. Но обычно, в результате получается 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 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2006, 19:07 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
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. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2006, 20:42 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
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. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2006, 20:57 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
Нет, вечером надо йти домой, а не сидеть за компьютером. Вечно что нибудь перепутаешь. Как это плохо, много знать. Последняя, третья попытка. Задачи автоматизации, стоящие перед IT-специалистами, они разные только при их поверхностном анализе. А на самом деле – они все одинаковы. И поэтому интерфейс для всех проектов может быть одинаковым. Только надо правильно представить задачу, т.е. предмет автоматизации. Не сочтите это за рекламу, но предлагаю посмотреть статью «Метод элементарных объектов» , который лежит в основе построения программного комплекса БАС . В результате – один и тот же bas.exe без всяких изменений применяется для решения совершенно разных (на первый взгляд) задач. А в интерфейсе, только несколько форм – ввод операций, лицевые счета, окно анализа результатов, окно распечатки отчетов, а также окна для настройки соответствующих режимов. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2006, 21:03 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
PVPЗадачи автоматизации, стоящие перед IT-специалистами, они разные только при их поверхностном анализе. А на самом деле – они все одинаковы. А я-то думаю, чего это столько прораммистов расплодилось?... Дармоеды, однако.... На самом-то деле задачи одинаковы при поверхностном анализе. Еще они одинаковы в элементарных функциях. А все остальное, к сожалению, всегда уникально... если речь идет не о тиражирвоании, но вы ведь не о нем?... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2006, 23:59 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
М.ГоловановА все остальное, к сожалению, всегда уникально... если речь идет не о тиражирвоании, но вы ведь не о нем?...Да нет, не о тиражировании. О разработке. Ну конечно, не всех абсолютно задач, а достаточно широкого класса - учетных и управленческих систем (вчера настроение было не достаточно серьезное, что бы ограничить область применения). Давайте посмотрим на операции обработки документов. Во всех них есть какая то шапка, детали и итоги. Шапка содержит параметры, которые относятся к операции в целом. Детали - список и параметры каких то элементов, ради которых построена эта операция. Заключение - мало чем отличается от шапки, просто немного другой аспект отражения данных. Но параметры заключения также относятся к операции в целом. Далее фукции - взаимосвязь между параметрами операции, взаимосвязи между параметрами деталей. То же самое можно сказать об отчетах, о справочниках. Все это одинаково. Отличие состоит в наборе и в названии параметров, а также в процедурах обработки их взаимосвязей. Я не утверждаю, что все формы одинаковы. Я утверждаю, что все они построены по один и тем же принципам. А значит программное обеспечение для их реализации - может быть построено одно, общее. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2006, 10:19 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
PVPЯ не утверждаю, что все формы одинаковы. Я утверждаю, что все они построены по один и тем же принципам. А значит программное обеспечение для их реализации - может быть построено одно, общее. Скажем с использованием одних и тех же команд Ассемблера ? Что есть кирпич в Вашем доме ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2006, 14:09 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
Ребята, что-то вы совсем не то написали, что я предлагал обсудить. К примеру, что не флудить, предлагаю обсудить способ описания requiements. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2006, 14:48 |
|
Дизайн приложения. Обсуждение темлайтов.
|
|||
---|---|---|---|
#18+
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. Да, и что вы хотели обсудить по поводу требований к ПО и их описания? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2006, 17:00 |
|
|
start [/forum/topic.php?fid=33&fpage=61&tid=1549450]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
56ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 236ms |
total: | 391ms |
0 / 0 |