Господа разработчики!

Предлагаю обсуждать и задавать вопросы, связанные с объектно-ориентированными методами, например, ООАП / OOAD (Object oriented Analysis & Design), моделированию с UML (Unified Modeling Language), а также другим смежным ОО-технологиям (COM/CORBA, .NET/J2EE, VB/Java/Delphi.., и т.п) и проектированию систем в данном топике(ветке).
Достоинства:

1. Не плодятся ветки и таким образом не засоряется форум.
2. Значительно облегчается поиск в форуме.
3. Одну ветку удобно потом сохранить из форума для получения своеобразного
решебника/FAQ, что бывает полезно не только для новичков.

Почему выбран раздел Проектирование БД , а не раздел форума по ОО-языку, например, Delphi или VB.NET? Во-первых, потому что объектно-ориентированные анализ и проектирование являются основными и часто с нетривиальными задачами важными стадиями разработки конечной целью к-рых является преобразование требований (в самом общем смысле слова) заказчика и пользователей в реализацию системы (архитектура и т.д). Слово "стадия" означает некую выделенность благодаря использованию свойственных этим стадиям методов или инструментария.
Во-вторых, потому что на данный момент на SQL.RU нет раздела форума наподобии "Проектирование приложений".

Добро пожаловать!

2 Yossarian:
Вопрос по Розе - вернее по UML.
Как моделировать взаимодействие классов, не укладывающееся в рамки
парадигмы посылки сообщений ?

Вообще с помощью диаграммы последовательности (ДП), т.е Sequence diagram можно моделировать все что угодно - не обязательно жизнедеятельности объектов, т.е являющихся class instance. Все зависит от того какой смысл вы вкладываете в ваше понятие "объект", т.е....

Например, у меня есть общая область памяти для 2х процессов. Они там друг другу ставят всякие флажки и работают совершенно асинхронно.

..создайте для этой области свой объект (класс) с соответствующим стереотипом, например, <<общая память>> или как там ближе по смыслу. Тогда установка флга в этой общей области будет выглядеть как сообщение одного объекта класса А, направленное к объекту <<общая память>>, т.е как это было бы аналогично вызову set-метода этого объекта. Тогда в процессе "ожидание флага готовности" объект, например, класса Б будет периодически посылать сообщение объекту <<общая память>> и проверять состояние флага что также можно отобразить условием "[flag set = true]". Асинхронные сообщения есть как тип в той же Rose,

...При этом есть, к примеру, ожидание разрешения доступа к этой самой общей памяти и есть ожидание флага готовности -это не одно и то же.. Хочется все это нарисовать на sequence
diagram так, чтобы было понятно.

сообщение себе (message to self) или самоделегирование - стрелка на себя и еще комментарий (text или note в Rose) c пояснением это если для "ожидание разрешения доступа к этой самой общей памяти". Других способов на ДП в UML по-мойму нет, в Rose точно нет

Но непонятно, как это нарисовать, потому что никаких методов вообще не вызывается ни разу.

Если это был бы результат ООП, то наверное это было бы нестандартно с точки зрения механизмов в ООП поскольку: сообщение - вызов/активизация метода объекта. . Даже если объект только и выполняет роль этой общей памяти. Но поскольку это может быть своеобразная или унаследованная система, то... Тем более UML предполагает очень общее понятие сообщения: "A specification of the conveyance of information from one instance to another, with the expectation that activity will ensue. A message may specify the raising of a signal or the call of an operation."

Даже о существовании друг друга классы узнают по косвенным признакам.

А как это выглядит на физическом уровне, т.е тоже по каким-то флагам в этой области? (когда оба знают друг о друге, то это отношение типа "bidirectional association" (UML) или "circular reference"(ОО языки) на логическом уровне, а на уровне реализации это указатель/ссылка на другой класс в каждом из классов)

Получается, надо рисовать 2 диаграммы : взаимодействие объекта с общей памятью (которая тоже реализована в виде объекта) и "логическое" взаимодействие объектов между собой, когда общая память используется как посредник.

Не знаю, я ведь не в курсе какие сценарии у вас в системе. Рисуйте такие ДП чтобы была понятно раскрыта суть вашего сценария/потока варианта использования (ВИ). Можно нарисовть и одну ДП на которой все . Я видел и такие модельки, не очень читабельно. Я, например, предпочитаю ДП для каждго основного потока (если это улучшает понимание программистам), а иногда и для исключительных или альтернативных потоков

Ссылок как раз никаких нет. Один объект это драйвер устройства. Он должен
работать всегда. И факт существования объекта, посылающего ему запросы, его не интересует.
Пришел запрос - обслужили. Не пришел - не надо

Ясно. Этот объект (драйвер) может быть на любой ДП, где он обслуживает чьи=то запросы

Второй объект должен сигнализировать о том, что ответ не пришел в заданное
время. Вариант - если не пришло несколько ответов подряд.

Это не сообщение типа Timout : In timeout synchronization, the client abandons a message if the supplier cannot handle the message within a specified amount of time. Вот ваша система и есть пример системы с такими сообщениями. Кстати, я RT-системами сталкивался как-то раз (сеть Atmel-устройств с RS-422 с PC-хабом на к-рый собирается технологическая информация) было это в 1999 г. я писал БД, но помню сплошной гемор у программистов писавших драйверы и связанный с тем, что обычная WinNT 4 была не RT, потом поставили какой-то Linux с RT-ядром или типа RT, т.е там задержка в драйвере устройства была постоянной и не зависила от частоты проца

То есть проблема в том, что объект А когда хочет послать сообщение объекту
В на самом деле вызывает метод объекта С. Объект В в свою очередь тоже
общается со своим объектом того же класса С. И это все в разных компонентах и разных процессах....

Ага, но к рисовать на ДП объекты вы можете, какая разница что они являются разными процессами? Также какая разница, что они взаимодействую не напрямую. Я пока не вижу противоречий UML. Мне кажется, что над вами как и надо мной давлеет ООПовость с ее "сообщение - это вызов метода", нет? :о)

2 funikovyuri: \r
как при разработке система на UML в дальнейшем не оказаться изолированным от существующих подходов к созданию GUI? \r
\r
Какие именно существующие подходы к созданию GUI имеются в виду?\r
\r
.. Как связать объекта и элементы управления? \r
\r
Точно также как связываются два объекта: статическая структура - диграмма классов, а поведение - диграммы взаимодействия\r
\r
.. Т.е. проблема как мне кажется, в том, что создатели инструментов для разработки интерфейса пошли другим путем - и вместо развития концепции работы с persistent объектами стали развивать концепцию объектов доступа с БД \r
\r
А какая связь между интерфейсом (пользовательским?) и моделью/механизмом доступа к БД? У них разные функции. То, что объекты GUI могут "содержать" data-aware объекты и контролы?\r
\r
поправка - я имею ввиду все же такие продукты как BCB/ADO/NET \r
потому что в Java, вроде, дела обстоят иначе \r
\r
А что в Java обстоит иначе? Там точно такая же объектная модель/иерархия с методами (интерфейсами), если брать JDBC или в виду имеется какой-то более низкоуровневый механизм? (как, например, в Swing используется MVC, т.е принципиально отличный подход или модель взаимодейстия от, например, MFC, использующего Document-View)\r
\r
\r
2 vdimas: \r
сейчас посоветовать для проекта под .NET набор инструментальных средств, но не могу объективно сравнить Visio с другими аналогичными продуктами, т.к. специально этим не занимаюсь. \r
\r
Может с этим CASE-вопросом лучше в Помогите выбрать CASE? Там можно будет обсудить конкретные возможности каждого из продуктов. Я бы также рекомендовал обратить внимание на XDE .NET Pro/Modeler/Developer, у к-го есть очевидные преимущества перед последними PD и Visio - интеграция с Rational Suite, т.е входящими в него различными средствами

2 funikovyuri: \r
Я хотел сказать, что элементы управления (DataAware) - они работают с датасетом, а не с произвольным объектом созданным PD и поддерживающий сериализацию/сохранение в БД \r
\r
Они для этого и не предназначались. Как уже сказал vdimas - для этого есть компоненты или встроенные/пользовательские классы, например, в тех же Java, VС или VB, предоставляющие функции (де)сериализации объектов raw/xml-поток, в файл/БД\r
\r
Далее интересно, не кто не создавал собственные расширения отображения OOM на ООП-языки(например C#) - т.е. отображения которое бы сразу формировало полностью рабочие классы с поддержкой сериализации? \r
\r
Т.е я так понимаю, что какая "проблема" в PD, если этот вопрос продолжение твоего поста (Дата: 17 сен 03, 11:53)?\r
\r
Далее, кто нибудидь использует встроенные в .Net механизмы сериализации объектов? \r
\r
Можно вопрос, чтобы говорить более предметно: зачем тебе нужна сериализация объектов?

2 vdimas:
Возьмусь ответить на вопрос не ко мне.

Наиболее используемый механизм работы с удаленным объектом сейчас - через удаленную ссылку-заместитель. ...............

Спасибо, что ты рассказал, что такое сериализация и для чего она может использоваться, но вопрос был несколько другой: зачем или для чего нужна сериализация именно funikovyuri , т.е чтобы можно было обсуждать стадию проектирования и конкретные вопросы "изображения" жизнедеятельнсти хранимых объектов с помощью того же UML и возможно вопросы их кодогенерации в CASE-средстве (например, в том же PD-OOM или XDE.NET), а не просто сериализацию саму по себе

2 funikovyuri:
Можно ли это использовать для сериализации persistent объектов в БД?

Что "это"?

По мотивам топика Вопрос крутым проектировщикам...:\\r
\\r
2 папа Карло: \\r
Вопрос простой и тривиальный.... \\r
\\r
Object это тоже самое что Entity? Пожалуйста ответьте односложно: да или нет. и привидите один абзац почему Вы так думаете. Не надо спорить с другим человеком просто напишите что Вы думаете. \\r
\\r
Дополняя уже вышесказанное "Yossarian". Вообще чтобы ответить на твой вопрос односложно или хотя бы кратко надо сначала спросить у тебя, где у тебя"Object" и "Entity" пересеклись, т.к в нек-рых ситациях "объект - это сущность...", а нек-рых "сущность - представляет собой множество объектов..."\\r
\\r
1) UML 1.5 Spec:\\r
Object - An entity with a well-defined boundary and identity that encapsulates\\r
state and behavior. State is represented by attributes and relationships, behavior\\r
is represented by operations, methods, and state machines. An object is an instance\\r
of a class. See: class, instance.\\r
\\r
2) ErWin Methods Guide:\\r
Entity - An entity represents a set of real or abstract things (people, places,\\r
events, and so forth ) which have common attributes or characteristics. Entities\\r
may be either independent, or dependent.\\r
\\r
Также можно ответить точно если знать какой вид (view) или этап разработки системы имеется в виду, т.к определение того же объекта будет отличаться на этапах анализа, проектирования и реализации \\r
\\r
2 U-gene: \\r
Вопрос1) Верно ли я понял, что в первом случае Entity равно "объект", а во втором - по смыслу приближается к понятию "класс" (т.е. объектом будет экземпляр сущности, некая thing из этого set)? \\r
\\r
Я именно и хотел показать, что вообще "объект" и "сущность" могут представлять по сути одно и то же понятие, но иметь просто разные названия. Четкие различия проявляются только на этапах проектирования и реализации при ОО и структурном подходе соответственно: объект может иметь как характеристики (данные), так и поведение (состояния), а сущность имеет только характеристики (данные). Дальше уже также могут появиться "объекты" в БД, но это уже не те объекты :о)\\r
\\r
Вопрос 2) Подразумевает ли первое, что могут существовать entity не являющиеся объектами ( ....аn entity without a well-defined boundary or without identity....и т.д.)? \\r
\\r
Опять же вопрос: какой этап/стадия ЖЦ имеется в виду и вообще чья точка зрения (т.з) ? Например, в ООАП (в книгах Трех амигос, Лармана и т.д) однозначно говорится, что на стадии анализа : а) описываемая предметная проблема (например, автоматизируемый бизнес-процесс) имеет границы (понятийные, пространственные, временные и т.д), б) число объектов предметной области и число классов ее объектов конечно . Однако понятно, что та же предметная область может расширяться, уточняться и т.д, но на определенной итерации необходима "заморозка", т.е "трогаем только это и то, а вот это не трогаем". Значит с т.з разработчика ИС и на определенной итерации данный объект (сущность) обязан обладать как бы определенными свойствами и имеет определенное поведение, т.е может быть описан с помощью класса. Но т.з, например, некого бизнес-аналитика, к-рый "видит" предметную проблему гораздо шире, допускает то, что данный объект не обладает определенными свойствами и может не иметь иметь определенного поведения. Так что завтра с его т.з этот объект вообще может если не исчезнуть, то стать другим объектом

2 vdimas:
Речь идет о том, чтобы перемещать объекты м/у хостами (потоками, процессами). Т.е. чтобы объект у нас "гулял" в системе, над ним выполнялись бы некие действия в каждой точке и передавали его дальше.

И как это отобразить в UML?

Что именно "это"? Как он "гуляет" по сети или как он живет на сервере/клиенте? Если как он живет на клиенте/сервере, то также как ты и сейчас изображаешь его жизнедеятельность, например

По мотивам топика Together for VS.NET Edition...\r
\r
2 vdimas: \r
Replicant, ja rad, chto ty u nas analitic. Otvet\' tol\'ko mne na prostoj vopros: kakoj protsent ot obschej trudoemkosti zanimaet sbor trebovanij i proektirovanie OBSCHEJ architecture, a kakoj - proektirovanie i realizatsija etoj architectury. \r
\r
Немного непонятно почему ты измеряешь трудоемкость в конкретных цифрах человеко-месяцев (3-4, 12-18...). У вас все проекты одинаковые по объемам работат? Что касается стоимости стадий, то у нас примерно похожее соотношение как и в организациях, где используется отлаженный и урезанный RUP (%% от суммарных проектных трудозатрат):\r
\r
получение требований/ВИ и анализ с построением модели ВИ/анализа/GUI - 15-20% ^*) \r

проектирование архитектуры с созданием модели проектирования/реализации - 15-20% ^*) \r

реализация (программирование, создание контента и т.д) - 20-40% ^*) \r

создание модели тестирования и тестирование - 2-5% \r

развертывание ("внедрение") - 5-10% ^*) \r

DCT/CM, планирование и др.вспомогательные деятельности - 2-5% \r
\r
^*) изменяется в зависимости от наличия опыта создания таких приложения, разработки под платформу, уже имеющихся шаблонов и т.п\r
\r
T.e. bol\'she vsego ljudej i vremeni uhodit na poslednie 2 punkta. Together mozhet uskorit\' v 2 i bolee raz eti poslednie 2 punkta. I kogo posle etogo volnijut neschastnye 3-4 chel/mesjatsa potrachennye analitikom? \r
\r
Может ты хочешь этим сказать, что деятельность аналитика или стадия анализа несущественна? То, что у тебя важнейшая стадия анализа съедает почти в 10 раз меньше (3-4 против 6-9 + 24), чем стадия проектирования (OO+ER), то это ненормально даже для каких-то особых требований к производительности, надежности и т.д архитектуры. Очень напоминает случай, когда требования/ВИ не собираются полноценно и анализируются, а модель проектирования выдумывается или "высасывается" из пальца, т.е не получается закономерно и обоснованно из модели анализа.\r
Что касается "ускорений 2 и более раз", то это возможно если ты мощными CASE-средствами не пользовался до сего дня :о)\r
\r
Replicant, ty voobsche kto? Analitik ili proektirovscik? Ili 2-v-odnom? \r
\r
Загляни в профиль - аналитик-проектировщик :о)\r
\r
.. Kak proektirovschiku mne prihoditsja razrabatyvat\' osnovnye struktury bazy dannyh i ierarhiju osnovnyh klassov (v sovremennyh busness-proektah eta ierarhija klassov mozhet legko perevalivat\' za 1000-u elementov suschestvujuschih v 10-ah chastej sistemy). ... \r
\r
Можно только "позавидовать" такому изобилию типов в бизнес-тире. Хотя, наверное, интересно! У нас же перевес в сторону РБД: несколько сотен таблиц, максимум пара сотен классов в бизнес-тире и десятки классов на клиентских местах\r
\r
.. V poslednem proekte analitik vydal mne spetsifikatsiju togo, chto hotjat zakazchiki, odnako on ves\'ma dalek ot arhitektury sistemy da eto i ne ego delo, ego delo - sobirat\' spetsifikatsii i trebovanija, pisat\' uses cases i tak dalee. Ja tak dumaju - ty dolzhen zanimat\'sja tem zhe, esli pozitsioniruesh\' sebja kak analitik. \r
\r
Я занимаюсь не только получением требований/ВИ с построением моделей, но и их анализом - это и есть работа аналитика (см.выше стадии). Если же упомянутый тобой "аналитик" только получает модель ВИ как конечный результат своей деятельности, то он не совсем полноценный аналитик (в российской ИТ-терминологии по его видам деятельностей, т.к он не получает концептуальную модель или модель анализа ), а скорее сборщик требований/ВИ . Но в RUP он и будет как раз requirements specifier (и requirements reviewer ), а также и system analyst , если он полностью выдает все, начиная от Vision и кончая моделью ВИ. В общем сплошные конфликты в терминологии и путаница. На самом деле очень не плохо, когда роли аналитика и проектировщика совмещаются одним лицом, т.к модель проектирования влияет (направляет, корректирует) на модель ВИ и соответственно модель анализа. В противном случае 2 человека, реализаующие эти роли должны плотно взаимодействовать и понимать суть не только своей, но и чужой деятельности\r
\r
Dalee. Posle razrabotki architektury klassov ja obychno imeju ne tol\'ko ee UML-diagrammu, no i real\'nye detall\'no spetsifitsirovannye interfejsy klassov vmeste s ishodnikami, kotoryje razdajutsja dlja implementatsii komande, prichem vse eto imeet vysokuju stepen\' gotovnosti, a kritichnye momenty ja voobsche nikomu ne doverjaju, razrabatyvaju i otlazhivaju ih vmeste so structuroj systemy. \r
\r
Вообще-то так и должно быть, если согласно какому-нибудь нормальному процессу типа RUP. Обобщая и переводя на кириллицу сказанное тобой: проектировщик и должен заниматься и тем более отвечать за архитектуру, а не программист - имеются в виду знания, навыки и тип мышления. Программисты получают необходимые модели/описания (ВИ, анализа, проектирования) и объявления. На первые они смотрят, а во вторые - пишут тела методов и т.д\r
\r
Ot otveta na vopros "mozno ili net v printsipe TAKOE sdelat\'?" zavisit VSJA architektura proekta. \r
\r
Да, можно, но при правильной методологии/процессе, к-рая соблюдается. А что такое "архитектура проекта"?

2 vdimas:
Под словом ТАКОЕ я имел ввиду моменты, которые однозначно сложны в реализации, но могут накладывать значительный отпечаток на архитектуру проекта. Под архитектурой понимаю совокупность составных частей проекта и их ролей в системе (подозреваю, что ты меня тестируешь на "книжный" вариант, но под рукой книги нет :). ...

Может ты все-таки имеешь в виду просто архитектуру системы и не роли, а просто назначение и приоритет ? Что-то я все чаще на SQL.RU встречаю злоупотребления сволом "проект". Но все равно интересно, что это за термин. А что за книжка хоть? :о)

.. Так вот распределение этих ролей (читай функциональной нагрузки) диктуется не столько возможностями CASE средств и квалификацией аналитика, сколько возможностями доступных технологий. ...

Если речь идет о функционале , т.е совокупности функций (пользовательские, служебные и т.д), реализуемых той или иной подсистемой , то, конечно, от CASE-средства он сам по себе никак не зависит, как и его функционала модель, если брать случай адекватного и добросовестного аналитика и не брать случай откровенно архаичного CASE-средства. Он также и не всегда зависит от доступных технологий, если не брать какие-нибудь исключительные случаи

.. Если ты умудряешься быть хорошим аналитиком и еще одновременно хорошим проектировщиком (т.е. разбираться до самого дна в куче применяемых технологий), то мне остается только позавидовать, т.к. это трудновообразимо. ...

А что имеется в виду под "до самого дна"? Проектировщик и не обязан разбираться "до самого дна", а только до такой степени, чтобы эффективно создавать архитектуру в заданных "рамках" проекта (стоимость решения, время и т.д). "До самого дна" разбираются пожалуй инженеры в MCS, но они занимаются, например, только теми же СУБД (MSSQL, Access, Jet, OLEDB, ADO и т.д) :о)

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

Это смотря какой объем знаний технологий и их глубину ты имеешь в виду. И потом сегодня период смены версии платформы (ОС, СУБД, офис и т.д) у той же Майкрософт составляет 2-3 года, а если учитывать, что заказчики с их "парком" приложений отстают от этой гонки также года на 2-3, то получается, что имеем период где-то в 4 года для жизни той же платформы. Далее надо учитывать ту базовую платформу (ОС, СУБД, сервер приложений), для к-рой вы создаете приложения, т.е если это Windows/*nix, NET/J2EE и т.д, то - да, список будет приличный и если не из технологий, то из продуктов точно. У нас же все исключительно крутится вокруг связки Windows-Office-MSSQL-IIS-CS-BT текущих и предыдущих версий так что не так уж и сложно

Кстати, вот здесь ты малость ошибаешься:

Ты хоть понял смысл того, что я сказал? То, что ты рассказал про архитектуру, к-рая может легко адаптироваться к изменениям БП не опровергает то, что говорил я, т.е для того, чтобы обновить бизнес-логику, содержащуюся в бизнес-тире тебе все равно будет нужна "заморозка". В противном случае ты сегодня "залил" в бизнес-тир ее новую версию, а завтра тебе заказчик говорит: "мы тут подумали - это надо сделать не так, а вот так...". Тебе может быть это, конечно, хорошо и наплевать на частые переделки, но заказчик ведь платит за каждую такую переделку, а ты ему еще говоришь: "Да ладно, давайте, не думайте со своим реинжинирингом! Наша архитектура любые крутые изменения сдюжит..."

Не все так плохо... Я как раз обычно борюсь с окружением за то, чтобы оставлять приличную степень свободы для дальнейшего проектирования, т.к. точка зрения может поменяться не только у аналитика, но и у заказчика или даже могут мутировать бизнес-правила. Помогает крайне четкое разделение элементов проекта на вещи общего плана и явно прикладного плана. Учитывая, что при таком грамотном разбиении 50% и более будут вещи общего плана - часть проекта мы уже спасли. :)

Вот это уже хорошее дополнение относительно создания самой архитектуры !

В том, проекте, что доделываю сейчас разработан специальный call-back механизм, автоматически (с помощью метаданных) связывающий события, происходящие на клиентских формах по обработке данных (View+Controller) c изменениями свойств конкретных бизнесс-объектов на middle-tier. Это дает приличную степень свободы разработчику middle-tier, т.к. в 90% случаях, при изменении логики работы, добавления или удаления свойств нет необходимости перерабатывать и заново отлаживать GUI, достаточно малость подкорректировать метаданные, да и функциональная нагрузка клиентской части порой отсутствует, формы создаются из описаний, никакого кода на клиентской части большинстве случаев не будет.

Да, тонкий клиент - это здорово. "никакого кода на клиентской части большинстве случаев не будет" - скорее всего почти никакого , т.к нуже вызов метода удаленного объекта, если это не Web-клиент. Как обстоят дела с проверкой (валидацией) вводимых значений "на лету" или проверкой заполнения полей, например, на Web-клиенте. Вы это тоже делаете на сервере (ASP.NET Web forms), т.е заставляете пользователя заполнять длинную форму, чтобы после нажатия кнопки [Применить] или что там он получил диалог с сообщением и снова вернулся к заполнению полей? Не знаю, но просто...

If the user is working with a browser that supports DHTML, the validation controls can also
perform validation using client script. This can substantially improve response time in the
page; errors are detected immediately and error messages are displayed as soon as the user
leaves the control containing the error. If client-side validation is available, you have
greater control over the layout of error messages and can display an error summary in a
pop-up message box. For more details, see Client-Side Validation.

С проверкой, валидацией, опимизицией этого дела, вызовов методов объектов... Мне просто не вериться! Объяснить как заставить это работать само?

Про валидацию данных и т.д c использованием Win Forms вопросов нет. Я спрашивал про Web-клиента, а если его нет, то и вопрос отпадает сам собой :о)

Объясни чего я не понял? Может мы разговариваем на разных языках (допускаю), или оперируем разной по величине дискретизацией времени?

Я не знаю чего ты не понял, но то, что ты что-то не понял - факт, т.к странно когда человек пишет "Кстати, вот здесь ты малость ошибаешься: " и далее вместо того, что показать, где ошибка или неточность он начинает рассказывать про архитектуру, к-рая легко адаптируется к изменениям БП. Что-то наподобии: а) шурупы нужно закручивать отверткой, б) нет, их можно забивать молотком как гвозди главное чтобы молоток был потяжелее

а если "рамка" проекта такая: разработать систему типа 1С только на .NET технологиях, 3-х слойка, 3 языка скриптов, + среда разработки?
+ на ней сделать пилотный бизнес-проект?
Это как делать без достаточного окунания в тот же .NET (у меня свой уровень достаточности...)

А что имеется в виду под "сделать ... бизнес-проект"? Что касается твоего проекта и "рамок", то высказывание: "Проектировщик и не обязан разбираться "до самого дна", а только до такой степени, чтобы эффективно создавать архитектуру в заданных "рамках" проекта (стоимость решения, время и т.д)." верно и здесь, и оно не противоречит тому, что в твоем проекте нужно хорошо знать .NET, а иначе о каком эффективном проектировании может идти речь. Просто мне было не совсем понятно, что именно означает "разбираться до самого дна"

Ну да, жаргон, это имеется ввиду система. Можно было просто высказаться о несогласии или неккоректном применении термина, а не растягивать на 2 поста.

Просто "проект" - это проект, а не система. Это разные вещи. А для жаргонов и просто болтовни есть форум Просто треп . Что касается 2-го поста, то в нем речь шла о функционале, а не о "проекте"

В .NET WinForms Microsoft предлагает использовать ErrorProvider Object вместо MessageBox. Очень удобно и гигиенично, рекомендую (как проектировщику). :)

Спасибо, а то я этого без тебя не знал :о)