5446

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 16 Апреля 2007, 20:18:22 »

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

Пусть в ходе выявления бизнес-требований был предложен такой ВИ:

Принять товарно-материальную ценность (ТМЦ)
1. Поставщик привозит ТМЦ и сопроводительные документы (счет-фактуру)
2. Кладовщик на основании счет-фактуры поставщика оприходует ТМЦ.
3. Кладовщик подписывает счет-фактуру и создает документ "Приход ТМЦ".
4. Поставщик идет в бухгалтерию.
5. Бухгалтер на основании подписанной кладовщиком счет-фактуры и, руководствуясь договором, выписывает счет на получение денег.
6. Поставщик со счетом идет в кассу.
7. Кассир выдает требуемую сумму и создает "расходный ордер".

Согласно моему пониманию я описал ВИ уровня бизнеса в стиле прозрачный ящик. Уровень обобщенный (могу ошибаться - просьба поправить)

Далее согласно процессу разработки я должен создать формализованную модель. С одной стороны модель должна быть независимой от платформы реализации с одной строны, но с другой стороны позволить эффективной трансформировать ее в модель реализации на 1С.
Для 1с существует жестко определенная структура классов? Документ, Справочник, Регистр, Перечисление, Операция, Проводка?

Очевидно, что Приход ТМЦ и Расходный Ордер  наследники абстрактного класса Документ с конкретной реализацией методов проводки, изменения состояния, записей в регистры, журналы операций и т.п.

Элементы документа могут быть справочниками, каждый из которых в свою очередь наследник некого класса Справочник

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

5447

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 16 Апреля 2007, 19:58:44 »

Вот пришла мысль немного пофилософствовать.

Возьмем Вашу задачу, Петро. Ясно теперь, что ваша задача лежит не в плоскости проектирования, а в плоскости реализации. С философской точки зрения мы можем сказать, что в принципе ваша задача разрешима когда-либо. Однако на современном уровне развития информатики, задача разрешима частным образом.

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

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

Что предлагает веб-технология для решения вашей задачи:
очевидно клиентский скриптовый язык (сюда думаю имеет смысл отнести и ajax)
использование плагинов, активных элементов (типа ActiveX): flash, svg и т.п.
использование систем типа java web start и т.д.

Пожалуйста в том же frontend'е можно при разработки страниц вставить оле-объект, в результате с информацией закаченной в него вы работаете на своем компьютере, но естествено обновление тербует связи с сервером, затрат времени и т.п.

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

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

Например я так и не смог понять в чем причина, необходимость такого решения? Почем так важен мгновенный отклик на скажем поисковый запрос? Или потребность технологии драг эн дроп в веб интерфейсе. В чем целесообразность?

Я понимаю, что если Вам удасться решить эту проблему, это не мало потешит Ваше самолюбие, а возможно Вы откроете нечто новое, заработаете на этом кучу денег:-)

Понимаете куда я веду? Важна цель!

5448

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 16 Апреля 2007, 19:24:45 »

красиво конечно.... Искуственный интеллект и т.д. Тока пока не получается с автогенераторами кода по модели UML.
Слишком много надо учитывать обстоятельст ЗА моделью.

ЗЫ. Надо будет попробовать на UML спректировать страничку выше-рисунок. Если абстрагироваться от ЯП, технологии, ...., то в модели остануться скриншоты-дизайн-прецеденты.

Понимаете в этом как раз и идеология MDA, когда создается так называемая платформонезависимая модель, на базе которой можно сгенерировать платформозависимые. Возьмите тот же Enterprise Architect, в котором как раз и есть примеры такого подхода. Вот уже на стадии PDM уже приходится привязать модель к реальному ЯП. Надо сказать, что технология MDA еще не прошла своего пика интереса и не вышла на полку стабильности. Эксперты утверждают, что процесс будет идти еще минимум 10 лет. Почитать можно в КомпьютерПресс за текущий год, в 1 номере кажется

5449

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 16 Апреля 2007, 13:19:10 »

Меня смущает какая-то сырость и зачаточность всего этого. Если для реализации ПОЛЬЗОВАТЕЛЬСКИХ требований клинета для десктоп-приложений всё делается с пол-пинка и естественным образом. То для Web нужно учитывать массу вещей-языков-технологий-способов_общения_клиента_с_сервером.
Почему, когда я пишу КС-десктоп-приложение, мне надо знать один язык программирования. Когда новичёк спрашивает: "С чего надо начать изучать Web-программирование?". Ему пишут: html+xml+JAVA+JAVA-Script+ActiveX+ASP+flash+...

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

При пректировании вам следует учитывать такие вопросы как архитектура системы, архитектура приложения, алгоритмы и т.п.

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

Особенность веб - это часто тонкий клиент и толстый сервер. Тонкость клиента можно изменить - на сегодняшний день это предполагает использования разных языков. Однако если вы например исполбзуете ASP и VBscript - вы имеете фактически один язык, то же можно сказать о Java и JS.

5450

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 16 Апреля 2007, 11:15:50 »

вчера опубликовал пост, а сегодня его не вижу. В чем проблема не могу понять.
В общем искал различную информацию по Ajax и наткнулся. Может Вам, Петро, будет интересно
http://forum.vingrad.ru/index.php?showtopic=58778&view=findpost&p=487774

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

5451

Проектирование / Re: Книги: Лешек Мацяшек - Анализ требований и проектирования систем. Разработка информационных сист

« : 14 Апреля 2007, 23:59:57 »

Мне не понравилась. Точно сформулировать почему не могу.
Да и объем не позволяет качественно рассмотреть все представленные вопросы. Т.е. не дотягивает - так некрепкий середнячок для студентов.

Книги разные нужны - книги разные важны. Все люди разные, уровень восприятия информации то же у разных людей разный.
Кроме того учебные, научные и технические книги требуют особого внимания и многократного прочтения. Лично я перечитываю книги по нескольку раз, порой по 10-ку раз. Читаю разные книги и возвращаюсь к прежним, понимание от прочитанного получается иным.
То что, в начале получается каша от прочитанного - это нормально. Нормальный процесс обучения: сначала получаешь сумму сведений (некоторое знание) - пытаешься эти знания применять - получаешь навык и умение - поступенно это перерастает в понимание. И тогда все становится ясным, простым и прозрачным.
Переход количества в качество - основной закон философии

5452

Проектирование / Re: Онлайновые учебные курсы по проектированию

« : 14 Апреля 2007, 23:53:39 »

Могу порекомендовать библиотеку учебных курсов в качестве некоторой альтернативы Intuit.ru от MSDN AA

5453

Проектирование / Re: Вопросы практики проектирования Web-приложения

« : 14 Апреля 2007, 23:48:55 »

P.S. Призываю быть более корректными, тем более с новым человеком. Наше ресурс не только для профессионалов в области анализа/проектирования, но и для людей, которые хотят что-то для себя прояснить.

А мне кажется дискуссия со стороны старожил вполне корректна. Просто вопрощающему нужно прислушаться к совету или четче выражать свои вопросы 

5454

Сообщество Аналитиков / Re: Рецензии на книги

« : 14 Апреля 2007, 23:44:15 »

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

Кроме того полезны рекомендации уже вышедших книг. Рынок книг велик и не все могут следить за ним и сделать выбор

5455

Примеры / Re: Моделирование деятельности деканата

« : 13 Апреля 2007, 20:58:49 »

Здрасти, а случаем ВУЗ который вы моделируете не СТАНКИН?
Очень мне напоминает его все бизнес процессы и система оценки студентов=)))
А вообще проблема многих ВУЗов нашей страны не в процесном подходе а функциональном=((, т.е. им не важен результат, им важен сама функция того или иного подразделения(кафедры)

Нет не СТАНКИН. Все нормальные вузы одинаковы, это только ненормальные вузы не нормальны по своему:-))
А насчет важности функции - все может быть, не замечал у себя...

5456

Примеры / Re: Генерация исходных кодов по средством создания UML модели

« : 13 Апреля 2007, 20:57:06 »

Код пока полноценно генерить никто не может, только шапки.

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

5457

Примеры / Re: Генерация исходных кодов по средством создания UML модели

« : 13 Апреля 2007, 19:02:59 »

Можно начать например с изучения чужого опыта.
UML и Rational Rose. Упражнения

Так же можно посоветовать практикум по проектированию ПО Вендрова А.М. Издательство "Финансы и статистика". Ну и конечно help help help, выбранного вами uml инструментария

5458

Идеи и мозговой штурм / Re: Расчет динамики

« : 13 Апреля 2007, 11:32:13 »

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

А вообще задача интересна.
Насчет того, что я невысоко мнения о коллегах - ну это не так, я же высказал, что вероятно народу эта тема не так близка или малознакома.

5459

Проектирование / Использование UML при проектировании задач в 1С

« : 13 Апреля 2007, 09:51:59 »

Я думаю, все хорошо себе представляют, что 1с является средой для разработки бизнес-приложений.

Проектирование решений в 1с на мой взгляд отличается от проектирования приложений "с нуля", например, в таких системах как Дельфи. 1С представляет собой конструктор конфигураций, базирующийся на четко выделенных элементах.
При проектировании фактически отсутствует необходимость разработки классов, базы данных.

Напомню, что в 1С используются такие объекты как справочники, документы, регистры, журналы документов, обработки и некоторые другие.
Справочники - представляют собой элементы хранения условно-постоянной информации
Документы - элементы, отражающие хозяйственные операции
Регистры - элементы, отражающие изменение состояние системы

На стадии бизнес-моделирования, анализа предметной области использование UML, кажется, не вызывает особых проблем.

Однако когда мы переходим уже к проектированию, а в дальнейшем и реализации, сразу возникает проблема - как использовать UML диаграммы, или возможно ли их вообще использовать в этом случае.

Хотелось бы начать дискуссию именно в этом направлении: можно ли, и как это возможно, использовать UML (ОО подход) для разработки конфигураций под 1С, как следует разрабатывать требования и проектные решения под 1С.

5460

Обучение / Re: Опыт преподавания объектно-ориентированного подхода в моделировании, анализе etc

« : 12 Апреля 2007, 20:43:34 »

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

Какие возникли проблемы?

Проблемы в том, что студенты не смогли идентифицировать проблемы четко. Получалось так, что ну нет у них проблем. Некоторые так увлекались, что решали проблемы не своего бизнеса, а чужого. Практически никто не смог поставить перед собою проблему. На семинаре я брал каждую задачу (напомню их четыре) и обрисовывал возможные вариатны проблем.
Например, по студенческому кафе - проблема достаточно больших отходов, невостребованных блюд. Или проблема или неудобство составления калькуляции блюд меню, когда меню достаточно большое, нужно рыться в справочниках, накладных, чтобы узнать нормы, количества имеющихся продуктов, входы этих продуктов. Или проблема готовки - проблема анализа потребного количества продуктов, нужно знать динамику посещения и востребованность блюд. Вручную это сделать сложно, кроме того требуюся довольно сложные алгоритмы вычисления тенденции...
Т.е. на семинаре я играл роль генератора этих проблем, призывал студентов к дискуссии, на доске выписывал их возможные проблемы, анализировал их, показывал цепочку рассуждений, которая приводила к необходимости использования Ит технологий. В конце концов рекомендовал просто вести учет материалов, продуктов, продаж и т.п. Что-то вполне является нужной задачей. Главное, чтобы студенты определили для себя направление в рамках их бизнес-случая и, отталкиваясь от него, начинали выстраивать цепочку рассуждений - проблема(задача) - цель - что есть - что хотелось бы иметь. А дальше уже пытаться выделить действующих лиц, которых затрагивает проблема или будущее решение, цели, потребности, желания этих ДЛ. Описание достижения этих целей, потребностей, желаний в виде вариантов использования по предложенному шаблону.

Одно занятие полностью посвятил примеру из Вигерса с расширением в визуальное моделирование.

В качестве задания предлагалось сделать презентацию образа решения в рамках выбранной проблемы или задачи. Предложить описание ВИ, их представление в виде диаграм деятельности (последнее просто для приобретения навыка работы с инструментами UML).
По замыслу у каждой пары должно быть не больше 4-5 вариантов использования.

В результате на отчетном занятии только 3 пары решились выступить со своей презентации. Ошибок было море - это естественно. К основным можно отнести:
1. отсутсвие обзорной модели Действующие лица - Цели(варианты использования)
2. нечеткое понимание цели своего проекта
3. при написании ВИ - плохо проработали исходные бизнес-процессы, а предыдущих заданиях  предлагалось точно описать как что делается
4. при написании ВИ семантические сложности, ошибки от которых предостерегал Коберн, путаница в уровнях ВИ

На презентации старался разбирать ошибки, показать как их исправить. Был в мыле. Результат: разочарование. Или народ не обучаем, либо совершенно нет никакой мотивации к изучению.
А как ее активировать?