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

Предлагаю обсуждать и задавать вопросы, связанные с объектно-ориентированными методами, например, ООАП / 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. Очень удобно и гигиенично, рекомендую (как проектировщику). :)

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

По мотивам иногородней ветки Комплексирование:SADT+UML (для целей структурного анализа бизнес-системы). ...

2 Р.Н.:
Хочу узнать ваше, мнение насчет, возможности объединения двух методологий для структурного моделирования бизнес-систем, посредством ведения общего глоссария проекта и использования двунаправленного (снизу-вверх, и сверху-вниз) процесса разработки структурной модели Системы.

Что такое "бизнес-система"/"Система" и каковы цели проекта? Если "Система" - это процессная система, т.е производство, организация или некая деятельность, то для ее описания вполне достаточно (хотя смотря, что требования к модели) ФСП, т.е SADT, т.к полученная модель "AS IS" может быть использована, например, для РБП и/или настройки коробочной ИС.
Если "Система" - это создаваемое вами ИС/ПО, то для ее создания достаточно и лучше использовать ООАП раз уж вы решились на методологический подход с моделированием.
Если же требуются обе модели и создается новая ИС, то есть определенные аргументы за то, чтобы не смешивать эти два очень разных подхода. "В одну телегу впрячь не можно коня и трепетную лань". Обсуждение этой темы было, кажется, в форуме Интерфейса - "Форум "Computer Associates" . Там есть поиск, но искать нужно за 2002 и 2003 года. Насколько мне помнится, там высказывался такой алгоритм: деятельности IDEF0 -> деятельности DFD <=> ВИ, т.е варианты использования - это эквиваленты деятельностей в модели DFD. Однако такой переход не всегда верен, например, с т.з ООАП, в к-ром ВИ не являются системными функциями

1. параллельно разрабатывается модель предметной области (ПО) (диаграмма классов) и функционально-структурная модель бизнес-процесса (SADT), формируется глоссарий предметной области состоящий из:словаря объектов ПО, и словаря функций, в ходе параллельной работы словари уточняются и дополняются, ..

А что такое "объекты ПО", т.е если это программные объекты или объекты БД, то какая связь ними и БП, описанными в SADT?

2. на основе анализа ФСМ выделяются прецеденты взаимодействия, анализируются требования к бизнес-системе (диаграммы прецедентов), на уровне ФСМ декомпозиция не производится, дальнейшее разделение функций посредством диаграммы прецедентов, ..

"на уровне ФСМ декомпозиция не производится" - то есть? В любом случае требуется декомпозиция контекстной функции

3. на основе построенных диаграмм прецедентов, с учетом модели ПО и словаря ПО строятся диаграммы последовательбностей. ..

А что такое такое "модель ПО" и "словарь ПО"? Модель ВИ как раз является моделью, описывающей, ЧТО должна делать система, т.е является частью концептуальной модели. А что за диаграммы последовательностей имеются в виду, т.е они относятся к модели анализа или к модели проектирования?

С учетом данного алгоритма осуществляется системное описание (морфология, функции, процессы) бизнес-системы.

Если вы хотите использовать ФСП даже для описания ИС, то зачем вообще связываться с ВИ?


2 Воронин Константин:
насчет SADT тоже размышлял... есть пожалуй аналогия между уровнями use-case у Кокбёрна и иерархией в IDEF0.

IMHO аналогия лишь внешняя, если только не понимать системные варианты использования (system use case), как функции, а это неверно с т.з (точки зрения) ООАП. У Коберна во "Writing Effective Use Cases" (WEUC) используется 3 уровня(level) описания ВИ с точки зрения протяженности во времени и вовлеченных в ВИ актеров ("1.2 Your use case is not my use case", page 22):

"Depending on the level of view needed at the time, the writer will choose to describe a multisitting
or summary goal , a single-sitting or user goal , or a part of a user goal, or subfunction .
Communicating which of these is being described is so important that my students have come up with two
different gradients to describe them: by height relative to sea level (above sea level, at sea level,
underwater), and by color (white, blue, indigo)."

..т.е ("Chapter 25. Appendix C: Glossary", page 246):

A "summary-level use case" is one that takes multiple user-goal sessions
  to complete, possibly weeks, months or years. Sub use cases can be any level
  of use case. Marked graphically with a cloud or a kite . The cloud is used
  for use cases that contain steps at cloud or kite level. The kite is used for use cases
  that contain user-goal steps.


A "user-goal use case" satisfies a particular and immediate goal of value
  to the primary actor. Typically performed by one primary actor in one
  sitting of 2-20 minutes (less if the primary actor is a computer), after which
  they can leave and proceed with other things. Steps are user-goal or lower.
  Marked graphically with waves .


A "subfunction use case" is one satisfying a partial goal of a user-goal
  use case or of another subfunction. Steps are lower-level subfunctions.
  Subfunction use cases support the user-goal use cases. They are only needed only
  are called from several by other use cases or isolate a complicated piece of behavior.
  Marked graphically with a fish or a clam . Using the clam signifies that the use case
  is too low level and should not be written at all.

В SADT же, как правило, используется функциональная декомпозиция , т.е представление функции или деятельности верхнего уровня в виде составляющих ее подфункций, связаных дугами, независимо от того сколько по времени, или одним или несколькими исполнителями (mechanism) выполняются эти подфункции

Мне кажется, если нет нужды в строго формальном описании, не стоит использовать SADT - лишняя работа и проблема с внесением изменений в модели.

Согласен с вами, если цель только создание собственной ИС, т.к SADT лучше всего подходит для описания бизнес-деятельности

Да и классические проблемы - куда отнести "печать документа на принтере" замучают :)

На самом деле проблема не в этом, т.к Р.Н. мог бы в Bpwin использовать вместе IDEF0 также и нотацию DFD для описания функций ИС, но в этом нет смысла, если цель - только создание ИС, т.к целиком ФСП типа SASD для создания ИС - это позавчерашний день

2 Р.Н.:
Как известно для комплексного описания любой социально-экономической / организационно-технической системы (бизнес-системы/Системы) необходимо описать три вида структур:
морфологическую , функциональную и процессную структуру.

А что значит "комплексного описания" и что вы имеете в виду под "функцией"? Т.е если под "функция" понимается также "свойство", "цель" и т.д, то, возможно, что такого описания будет достаточно, но опять все зависит от целей

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

То есть одна из ваших целей - выбор некого метода для разработки методики, т.е методов или методологии структурного моделирования? Также догадываюсь, но что именно имеется в виду под "задачей системного анализа"? Свой вопрос в форуме CFIN.RU Реинжиниринг, системный анализ не пробовали задавать?

предметная область---(методика)---(модель)---модель процесса ....

А показывает эта схема?

.. но может быть я идеалист,меня интересует возможность логического комплексирования SADT и UML через "мостик" USE CASE, который не является классическим объектным представлением, а является некоторым логическим методом определения контекста системы и в данном смысле слова является аналогом контекстной диаграммы - ICOM - блока.

Ради корректной терминологии: варианты использования (Use Cases) - это не метод (т.е это все равно, что сказать, что UML - это метод), а формат или способ описания поведения актеров и системы. Насчет контекста системы согласен, но не понятно почему ВИ являются аналогом контекстной диаграммы , т.к ВИ не являются функциями и для них не используется функциональная декомпозиция (при корректном использовании, например, в ООАП процессах) - см.выше пост Воронину Константину , т.е там нет "контекстного ВИ" вроде "UC0 Обслужить всех актеров" с разбиением на "составляющие ВИ"

(WEUC, 25. APPENDIX C: GLOSSARY)
A use case expresses a contract between the stakeholders of a system about
its behavior. It describes the system’s behavior and interactions under various
conditions as it responds to a request on behalf of the stakeholders, the primary
actor, showing how the primary actor’s goal gets delivered or fails.
The use case collects together the scenarios related to the primary actor’s goal.

use case (RUP v.2003, Glossary)
A description of system behavior, in terms of sequences of actions. A use case should
yield an observable result of value to an actor. A use case contains all flows of events
related to producing the "observable result of value", including alternate and exception
flows. ....
The specification of a sequence of actions, including variants, that a system (or other
entity) can perform, interacting with actors of the system.

.. мне же интересна логическое комплексирование, то есть возможность применение различных методов, как например в ARIS, но с использованием более популярных методологий (SADT b UML).

А зачем нужен SADT, если используется ARIS? Т.е нотация EPC позволяет более полно описать процесс (в этой нотации больше элементов, чем даже в IDEF3),а для упрощенного описания поддерживается обычное дерево функций. Также в методах ARIS и средствах автоматизации типа ARIS Toolset/Designer, а также других, к-рые могут работать с ARIS ( ArcStyler MDA-Bustiness Transformer : а) процессные модели (EPC), модели данных (EM) и объектные модели (UML) могут совместно существовать как различные виды(view) на структуру предприятия и б) их объекты могут иметь связи трассировки, т.е объекты одних моделей могут быть автоматически и "гладко" преобразованы в объекты других. Вот, например, ArcStyler MDA-Business Transformer Modeling Style Guide For ARIS

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

Здорово! :о)


2 cvoronin:
Не уверен насчет (не)правильности с точки зрения ООАП. Ведь use-cases, вообще говоря, никакого непосредственного отношения к нему не имеют - это просто удобный способ для описания требования к системе.

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

А аналогия же вот чем навеяна. И у Кокбёрна, и у в IDEF0 берётся нечто верхнего уровня и потом это нечто раскрывается на более низких уровнях.

Да, но природа у декомпозиций разная: продолжительность/вовлеченные_актеры (Коберн (кстати, он сам против, чтобы его читали как Кок берн, т.е "петух, чл..н")) и функциональная (IDEF0). Не говоря уже про остальное, как вы сами верно заметили ниже

Ссылка на продолжительность при желании ;) легко обходится тем, что для высоких уровней прецедентов временные рамки не предполагаются :)

Как можно ее обойти если это неотьемлимая характеристика общего (summary level) ВИ, т.е он является таковым, если он "длится долго и/или в нем принимают участие разные актеры со своими целями"?

Есть, разумеется, и отличия. В частности, разная схема связей. В случае прецедентов она "более сетевая", а не ограничена одним (по количеству) отношением "входит-в". ....
... но типичная структура use-case'ов в функциональную иерархию не уложится (за счет extends, includes в частности). ......

Совершенно верно! Причем IDEF0 как раз и хорош своей функциональной "детализацией внутрь", например, при ФСА :о)

По мотивам иногородней ветки Не понимаю какие типы диаграмм использовать ...\r
\r
2 trotski: \r
У меня индийский заказчик уже год требует документацию на UML. Программа давно готова и писать под уже существующее не понимаю как. \r
Диаграмма классов - понятно, вопросов никаких. \r
Для драйвера написал Activity Diagram. А какую диаграмму использовать для описания работы с GUI? У меня 5 модальных окон, происходит прокрутка данных(аудиоредактор) выделение куска, фильтры и т.д. \r
Посоветуете? \r
\r
1. Лучше, чтобы заказчик сам объяснил, что он хочет от этих диаграмм. Это можно сделать буквально в двух словах: "диаграммы должный описывать это.. и это.. так.. и так".\r
Для описания модели GUI ("статической") необязательно использовать диаграммы UML, а можно использовать нарисованные, например, в MS Visio 2000-2003 с использованием Windows User Interface (Shapes: Software > Windows & Dialogs, Toolbars & Menus, Icons, Common Controls, Wizards ; Extras > Callouts и т.д).\r
Для стандартных ФХД приложений (учет, торговля и т.д) такая модель GUI делается очень быстро и просто, содержит все окна, диалоги и органы управления (контролы) приложения, а также пояснительные комментарии (ссылка на ВИ или просто текст "закрывает окно и завершает текущую сессию") к ним и показывает заказчику реальный вид будущего GUI (если не используются какие-нибудь навороты с GUI вроде пользовательских скинов, контролов и т.д).\r
Такая модель + описание системных вариантов использования/ВИ (Use Case) + нефункциональные требования (например, допустимые значения) + возможно прототип - это все, что нужно для работы с заказчиком, чтобы понять, что он хочет от L&F приложения, т.е соответственно для описания внешнего "вида" и функциональности\r
\r
2. Если заказчик требует, чтобы даже для модели GUI использовался UML, то можно использовать диаграммы деятельностей/состояний, чтобы показать последовательность использования контролов в ВИ, т.е в дереве модели в узле ВИ, помимо обычных диаграмм классов, взаимодействия и т.д, раскрывающих суть ВИ, содержатся еще и эти диаграммы. Например, в книге Лешек А. Мацяшек. «Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.» (М.: «Вильямс», 2002. – 432 с., ISBN 5-845-90276-2, м/о) в главе 7.6.2. Диаграмма навигации по окнам и в 9.2.2. Диаграмма навигации по программе показано как использовать диаграммы деятельностей-состояний для этих целей. Также в топике Пример проектирования в Rational Rose есть ссылка на сайт Мацяшека, где он выложил модели в Rose к своей книге.\r
Однако IMHO такие диаграммы...\r
\r
не так просты для восприятия заказчиком, как модели Windows GUI в Visio,\r
  т.е они используют кучу стереотипов типа <<выпадающий список>> вместо\r
  реального вида контрола;\r

избыточны при наличии полных (full dressed) спецификаций ВИ и описывающих\r
  альтернативные и исключительные потоки/пути сценария, т.е уже есть текст,\r
  описывающий работу пользователя с GUI;\r

не всегда несут в себе достаточно информации: например, у Мацяшека на стр.308\r
  стрелка перехода состояния (state transition), соединяющая кнопки "Save" и "Clear"\r
  c границей окна (state), т.е показывающие, что состояние GUI не меняется\r
  и больше ничего - хотя также можно использовать дополнительные комментарии,\r
  описывающие команду, связанную с контролом.

... Но почему программистов искусственно делят на "быдло" - им только public методы доступны, и "элиту" - им еще и protected?

Вы все справедливо заметили, но ваш вопрос к тем, кто и проектирует классы/компоненты подобным образом. Причин подобных ляпов может быть сколько угодно: от банальной неграмотности, не понимания собственной системы в целом (т.е ЧТО должно быть "видно" и зачем) и кончая проектированием в попыхах или в режиме "low priority", т.е просто тяп-ляп :о)

2 mir:
Где та грань, которая четко отделяет protected метод от public метода?

Грань выбирается (я не беру случаи, когда проектирование делается тяп-ляп) из очень простых соображений, например, целесообразности и простоты интерфейса: public методы - чтобы удовлетворить типичные потребности при использовании объекта, protected - чтобы использовать нестандатрные и дополнительные возможности (их может быть масса), т.е в производном классе я могу их использовать; из соображений безопасности: public методы - обязательно должны содержать проверку передаваемых значений, protected - могут не содержать, т.к в производном классе может быть реализована своя проверка и т.д и т.п

И вообще, нужны ли protected методы даже теоретически?

Теоретически - да, т.к без них не реализовать все возможные типы видимости, к-рые могут понадобиться разработчикам. Например, MSDN ("Visual C++ Documentation"):

Class members declared as protected can be used only by the following:

* Member functions of the class that originally declared these members.
* Friends of the class that originally declared these members.
* Classes derived with public or protected access from the class that originally
declared these members.

Direct privately derived classes that also have private access to protected members.
Protected members are not as private as private members, which are accessible only to members
of the class in which they are declared, but they are not as public as public members, which
are accessible in any function. ....

Практически также бывают нужны, но, конечно, реже, чем public методы