Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: Galogen от 13 Апреля 2007, 09:51:59
-
Я думаю, все хорошо себе представляют, что 1с является средой для разработки бизнес-приложений.
Проектирование решений в 1с на мой взгляд отличается от проектирования приложений "с нуля", например, в таких системах как Дельфи. 1С представляет собой конструктор конфигураций, базирующийся на четко выделенных элементах.
При проектировании фактически отсутствует необходимость разработки классов, базы данных.
Напомню, что в 1С используются такие объекты как справочники, документы, регистры, журналы документов, обработки и некоторые другие.
Справочники - представляют собой элементы хранения условно-постоянной информации
Документы - элементы, отражающие хозяйственные операции
Регистры - элементы, отражающие изменение состояние системы
На стадии бизнес-моделирования, анализа предметной области использование UML, кажется, не вызывает особых проблем.
Однако когда мы переходим уже к проектированию, а в дальнейшем и реализации, сразу возникает проблема - как использовать UML диаграммы, или возможно ли их вообще использовать в этом случае.
Хотелось бы начать дискуссию именно в этом направлении: можно ли, и как это возможно, использовать UML (ОО подход) для разработки конфигураций под 1С, как следует разрабатывать требования и проектные решения под 1С.
-
Чтобы дать пищу для обсуждения, хочу предложить для развития такой простой пример.
Пусть в ходе выявления бизнес-требований был предложен такой ВИ:
Принять товарно-материальную ценность (ТМЦ)
1. Поставщик привозит ТМЦ и сопроводительные документы (счет-фактуру)
2. Кладовщик на основании счет-фактуры поставщика оприходует ТМЦ.
3. Кладовщик подписывает счет-фактуру и создает документ "Приход ТМЦ".
4. Поставщик идет в бухгалтерию.
5. Бухгалтер на основании подписанной кладовщиком счет-фактуры и, руководствуясь договором, выписывает счет на получение денег.
6. Поставщик со счетом идет в кассу.
7. Кассир выдает требуемую сумму и создает "расходный ордер".
Согласно моему пониманию я описал ВИ уровня бизнеса в стиле прозрачный ящик. Уровень обобщенный (могу ошибаться - просьба поправить)
Далее согласно процессу разработки я должен создать формализованную модель. С одной стороны модель должна быть независимой от платформы реализации с одной строны, но с другой стороны позволить эффективной трансформировать ее в модель реализации на 1С.
Для 1с существует жестко определенная структура классов? Документ, Справочник, Регистр, Перечисление, Операция, Проводка?
Очевидно, что Приход ТМЦ и Расходный Ордер наследники абстрактного класса Документ с конкретной реализацией методов проводки, изменения состояния, записей в регистры, журналы операций и т.п.
Элементы документа могут быть справочниками, каждый из которых в свою очередь наследник некого класса Справочник
Вот и интересно как наиболее оптимально тут действовать? Имеет ли смысл создавать независмую модель? Не увеличивает ли это трудоемкость? И вообще применима ли технология UML или вернее имеющихся процессов разработки, ориентированных на UML, в реализации проектов на 1С? Или требуется идти совсем другим путем?
-
Принять товарно-материальную ценность (ТМЦ)
1. Поставщик привозит ТМЦ и сопроводительные документы (счет-фактуру)
2. Кладовщик на основании счет-фактуры поставщика оприходует ТМЦ.
3. Кладовщик подписывает счет-фактуру и создает документ "Приход ТМЦ".
4. Поставщик идет в бухгалтерию.
5. Бухгалтер на основании подписанной кладовщиком счет-фактуры и, руководствуясь договором, выписывает счет на получение денег.
6. Поставщик со счетом идет в кассу.
7. Кассир выдает требуемую сумму и создает "расходный ордер".
не знаю, важно ли это, но у нас в аптеке очень большая номенклатура (тысячи наименований в день), поэтому поставщики привозят бумажные документы, а в 1С приходная формируется:
- модем - файл в формате поставщика (кто во что горазд)
- конвертер (сам писал) их формата в XML 1C
- 1C в меню берёт этот файл и формирует приходную
Согласно моему пониманию я описал ВИ уровня бизнеса в стиле прозрачный ящик. Уровень обобщенный (могу ошибаться - просьба поправить)
имхо чёрный ящик для каждого пунтка ВИ
Далее согласно процессу разработки я должен создать формализованную модель. С одной стороны модель должна быть независимой от платформы реализации с одной строны, но с другой стороны позволить эффективной трансформировать ее в модель реализации на 1С.
да! Противоречие. Я считаю, невозможно проектировать, не учитывая стандарты построения архитектуры системы.
Для 1с существует жестко определенная структура классов? Документ, Справочник, Регистр, Перечисление, Операция, Проводка?
да.
спр = СоздатьСправочник(Номенклатура)
спр.СоздатьНовый(ыыыыыыыы)
Очевидно, что Приход ТМЦ и Расходный Ордер наследники абстрактного класса Документ с конкретной реализацией методов проводки, изменения состояния, записей в регистры, журналы операций и т.п.
Элементы документа могут быть справочниками, каждый из которых в свою очередь наследник некого класса Справочник
я не много писал на 1С (жена иногда заставляет), но у них нет наследования и классов. Поэтому сложности с моделью.
Вот и интересно как наиболее оптимально тут действовать? Имеет ли смысл создавать независмую модель? Не увеличивает ли это трудоемкость? И вообще применима ли технология UML или вернее имеющихся процессов разработки, ориентированных на UML, в реализации проектов на 1С? Или требуется идти совсем другим путем?
у меня за спиной 1С-ники, так они чаще используют диаграммы переходов (или как там их называют с ромбиками :))))
-
Хочу вас обрадовать: решение по разработке OOM для 1С уже есть.
Уж не знаю, разрабатывал ли кто-то подобное до нас (про OOM), но нам пришлось интегрировать 1С-ную конфигурацию с .Net'овким решением. Причем отправной точкой для нашей конфигурации было 1С:Управление торговлей под 1Cv8. так что встал вопрос о том, что процесс разработки следовало бы сделать более управляемым.
В итоге было решено использовать Sybase PowerDesigner 11 и его OOM-модель. Определили классы 1Cv8, описали атрибуты. Получилось все очень даже красиво: конфигурация бьется по предметным областям, наглядно отображаются взаимосвязи между объектами, в т.ч. и генерация объктов на основании друг друга.
Огромный плюс: до того, как ваять конфигурацию в 1С и потом все переделывать, можно сначала все нарисовать и проанализировать. Далее ребята совершенстсовали модель без моего участия и, кажется, им даже удалось осуществить генерацию OOM-модели в конфигурацию. Но совершенно точно могу сказать, что им удалось сгенерировать OOM-модель на базе уже существующей конфигурации. Собственно, это не должно представлять особой трудности, если иметь доступ к конфигурации как к COM-объекту.
До этого искали что-то подобное на просторах Интернета, но ничего не нашли. Самый "продвинутый" продукт позволял невнятно изобразить графически конфигурацию в виде сущностей и связей. Но, если вы представляете количество объектов в базовых конфигурациях 1С, то можете представить и то, как вся эта конфигурация выглядит графически на одном полотне.
Если есть интерес — я могу поднять модель, которую начинал делать я. По поводу продвинутой версии не могу гарантировать, т.к. я уже давно не работаю в этой конторе.
-
Выкладывайте конечно.
Если не сложно, то не плохо запросить и более новую модель.
-
Если есть интерес — я могу поднять модель, которую начинал делать я. По поводу продвинутой версии не могу гарантировать, т.к. я уже давно не работаю в этой конторе.
ДА ДА ДА, не было бы не публиковал.
Объясню причину. Мы много говорим и изучаем ООМ, а зачастую студенты делают проекты для организаций под 1С, и теряются в использовании ООМ для этого, да что говорить нетолько ООМ но И ЕР, разве немного Use Case или IDEF0 или 3. Но никакой полной картины нет. правда мы пока юзаем 1с7, но будем закупать программисткую лицензию по 540 за штуку.
Было бы очень не плохо совместить в курсе КИС и разработку конфигурации и ее реализацию. Реализация у меня есть - несколько примеров раззжеванных до тошноты, а хотелось бы что бы студенты сами во второй половине семестра сделали свою конфигурацию и при этом использовали знания по ООМ...
-
Итак, модель я заполучил. Что-то изобразить с ее помощью можно, но не реализована генерация объектов конфигурации 1Cv8 и реинжиниринг. Первое, на самом деле, было заточено под .Net для доступа к конфигурации, а вторая часть оказалась слишком трудозатратной.
Если кому-то интересно - пишите в личку адреса электронной почты, я буквально в тот же день вышлю вам .xol-файл (это описание объектной модели для Sybase PowerDesigner). Предупреждаю сразу, что файл заточен под 11-ую версию, так что как младшие или старшие будут с ним работать, ничего сказать не могу.
Заодно, если кому-то нужно, есть PD 12.1 с лицензией.
Вообще, объясните мне, пожалуйста, как такой гигант, как 1С, до сих пор так нелогично относится к процессу разработки конфигурации? Хотя, не в обиду будет сказано 1С-разработчикам, способы разработки продуктов на этой платформе очень ощутимо отличаются от общепринятых...
-
Если кому-то интересно - пишите в личку адреса электронной почты, я буквально в тот же день вышлю вам .xol-файл (это описание объектной модели для Sybase PowerDesigner). Предупреждаю сразу, что файл заточен под 11-ую версию, так что как младшие или старшие будут с ним работать, ничего сказать не могу.
Денис, нет у меня Дизайнера. Отказался от него, вернее есть 9.5, но давно не используется. Да и если честно, после других систем возвращаться пока к дизайнеру неохота. Потому нет ли у дизайнера возможности сохранять модели в формате, который могут понять Rational Rose 2003, Enterprise Architect, Telelogic Tau, Together, Visual Paradigm, Visio наконец. :-))
Заодно, если кому-то нужно, есть PD 12.1 с лицензией.
Стоит ли разрабасываться лицензией, еще осудять как Поносова :)
Вообще, объясните мне, пожалуйста, как такой гигант, как 1С, до сих пор так нелогично относится к процессу разработки конфигурации? Хотя, не в обиду будет сказано 1С-разработчикам, способы разработки продуктов на этой платформе очень ощутимо отличаются от общепринятых...
А зачем. Изначально это была коробочная версия с постпродажным или пост внедренческим обслуживанием. Причем вторая статья превалирует в доходной части и существенно. Например купили лицензию на рабочее место скажем за 10 тыс + всякое там ослуживание где-то 2-3 тыс в мес. уже через год это становится = 24-36 тыс. А если нужна адаптация стандартной конфигурации - а она практически нужна всегда - поскольку аже такие огранизации как вузы - вроде чисто бюджетную имеют бухгалтерию и по идее должны иметь единый набор процессов и их сценариев, все равно требуют переделки. Переделка в целом типичная и довольно понятная - тянет обычно тыс на 30-40 р. как минимум. Так что как понимаешь бабки крутятся - народ одинэсит во всю...
У меня был такой опыт - пивоваренная компания вышла на меня каким-то неизвестным мне образом - якобы я самый главный специалист в городе по корпоративным информационным системам :) - поговорили с людьми: товарищам хотелось через месяц получить конфигурацию управления складом, но с очень большими дополнениями и двойной бухгалтерией конечно. Я конечно ни какой не спец был, да и есть, просто читал курс по ERP :-). 1С только начинал осваивать. Однако поговорив с людьми, естественно загрузил их по полной программе. Сказал что за месяц, если и можно сделать но наверное еесли будут работать сразу 100 человек, да и то не возможно - будут друг другу мешать. В итоге я помог им связаться к компанией IT-soft, узнал примерно через полгода, что они даже пока еще не утвердили полностью ТЗ. Еще через год - был сделан проект, который даже был примерирован, а конфигурацию было решено внедрить на других пивоваренных площадках страны...
Однако в личных раговорах с разработчиками я понял, что никакие IDEF, UML, и другие нотации не используются, и даже не стремятся использоваться. Аргумент был таков, а как это нам использовать? Базу мы не разрабатываем, классов как таковых у нас нет - всю библиотеку мы имеем от движка, а что своего разрабатываем, то мол это свои dll, выгрузки, и т.п.
Я им пытался сказать, что мол ну и что - не путайте божий дар с морковкой. Одно другому не мешает. Они как-то предложили мне рассказать им об скажем использовании UML, но я к сожалению не был тогда столь подкован-раз, да и просто кому-то доказывать что-то, особенно когда люди явно настроены против.
Еще мысль - 1С-ники подготовили хорошую систему обучения и сертификации, стиль разработки конфигураций больше напоминает процедурный подход с хорошо развитыми библиотеками и приемами работы
-
Интересно будет посмотреть.
Что-то сейчас по проектированию под 1С существует?
Покажите.
-
Доброго времени суток!!! Плизззз.... :-\
Поделитесь опытом построения UML диаграмм для бизнес-процессов провайдера связи (в частности интеграция биллинга с 1С:Бухгалтерией 8). Вообще интересно, насколько раскручено проектирование бизнес-процессов 1C с помошью UML?? Это актуально сейчас?? ???
-
Так я и тему открыл, что бы это же самое узнать.
Насколько я понимаю этот вопрос, моделирование бизнес-процессов никак не определяется для или не для 1 С это делается. Я таки полагал другое, как используя метамодель 1С применять UML моделирование - возможно ли это или нет?
Однако на мой взгляд - это сильно коррелирует и с тем как применять UML при программировании на Дельфи, где широко используется программирование с использованием компонентов и вообще при компонентном подходе в разработке.
Конечно, при моделировании и проектировании функционала для 1С мы могли бы скажем сделать библиотеку объектов, компонентов, классов с соответствующими стереотипами. В принципе я помогал одним разработчкам применить моделирование данных в РОзе для конфигруации (вернее БД) под 1С. Правда там ситуация была несколько иная, хотя и похожая.
-
Сейчас пытаюсь начертить диаграммы UML ...Вот получилось что : отвратительно некрасивая Диаграмма классов и еще хуже UseCase :o :o :o :o :o подправьте ::) Задача диплома такая: автоматизация проектирования задач обмена между биллинговой и бухгалтерской(1С) системами!! Интеграция проиисходит с помощью внешней обработки(на 1С) на уровне файлов XML. Обмениваются системы данными: о клиентах, о договорах, о платежах. Хочу сначала с помощью UML показать бизнес-процессы провайдера, а потом детализированно описать модуль инетеграции и кто из акторов с ним работает...путаюсь...пугаюсь
-
и вот еще диаграмма классов...это уже по самому модулю интеграции биллинга с 1с
-
вот какая сейчас. Я думаю, что доработаю свою UML диаграмму до стадии проектирования обмена в 1С....поэтому ::)прошу прощения за моё присутствие в ЭТОЙ теме :)
-
вот я тут передумала кое-что, предоставляю неоконченное описание бизнес-процессов компании провайдера. Думаете много еще надо исправить? ;D
-
вот я тут передумала кое-что, предоставляю неоконченное описание бизнес-процессов компании провайдера. Думаете много еще надо исправить? ;D
-
А где описание? Посмотрю на днях, как немного время освободится.
-
Коль скоро это диплом, и тема -- интеграция, то не факт, что я стал бы рисовать UC. Для начала нужно описать процессы в рамках которых происходит интеграция, именно процесс, т.е. описать динамику. Для этого можно использовать хоть тот же BPMN ... отсюда выходим на регламент взаимодействия двух систем. В качестве средства интеграции можно взять не файлы а какой-нить MOM ... и потом в дипломе привести интеграционный сценарий в BEPL, поддерживаемый данным MOM.
-
итак. Вот моё эксклюзивное описание самой разработки модула сопряжения :-X требуют UML диаграммы ... у меня специальность САПР ... а BPwin уже в дипломе использовала для описание этапов разработки АС...преподы требуют использования более одного CASE-средства
P.S. вот спасибо :) узнала еще BPMN и кое-что про BEPL, интересно , но не то :-\ я на последней стадии написания диплома...нет времени перестраиваться
-
Диаграмма активности--"предоставление услуг абоненту"
-
В принципе, мое ИМХО, затронута тема моделирования бухучета. Можно же это делать не в привязке к 1С, т.к. существует множество систем ведения бухгалтерии. Практически все они оперируют одними и теми же сущностями. Думаю можно сделать срез «ядра» такой системы, т. е. определить для начала классы, их операции. Смоделировать поведение объектов при взаимодействии друг с другом и т. д.
-
Диаграмма активности--"предоставление услуг абоненту"
Я не совсем понял, зачем в диаграмме используются распаралелливание перед шагом 3 (толстая горизонтальная черта)??? Где там распараллеливание вообще? И какие параллельные активности синхронизируются перед End ?
-
Я думаю, все хорошо себе представляют, что 1с является средой для разработки бизнес-приложений.
Однако когда мы переходим уже к проектированию, а в дальнейшем и реализации, сразу возникает проблема - как использовать UML диаграммы, или возможно ли их вообще использовать в этом случае.
Хотелось бы начать дискуссию именно в этом направлении: можно ли, и как это возможно, использовать UML (ОО подход) для разработки конфигураций под 1С, как следует разрабатывать требования и проектные решения под 1С.
Добрый день, коллеги.
Рискну предложить вам своё видение использования возможностей UML в проектах 1С 8.2.
Данная методика в первую очередь предназначена для аналитиков владеющих UML, но ранее не сталкивавшихся с системой 1С:Предприятие 8.*.
http://www.ильяфедоров.рф/ITMANE_ITM18_IAFedorov_DiplomPublication.pdf (http://www.ильяфедоров.рф/ITMANE_ITM18_IAFedorov_DiplomPublication.pdf)
Сама идея и возможности более обширны чем представленные в этой работе, возможно часть моментов сомнительны с точки зрения практического использования, для меня лично конкретная польза от её применения есть и понимание актуальности поднятых вопросов со стороны коллег тоже.
Буду рад конструктивной критике и вопросам.
Спасибо.
-
Я рисую use-case для ЗУП 2.5. Просьба оценить
-
Есть собственная разработка 1С:Система проектирования прикладных решений (v8.1c.ru/model/?printversion=1).
-
Я рисую use-case для ЗУП 2.5. Просьба оценить
Нарисованы не способы применения, а функции/фичи системы.
-
Тогда варианты использования, что это по Вашему?
-
Тогда варианты использования, что это по Вашему?
Это связка «Глагол» + «Результат», ради которого происходит сеанс работы с системой или их серия.
У набора инструментов могут быть способы применения, например:
Системные:
1. Забить гвоздь
2. Закрутить шуруп
Бизнесовые:
1. Собрать шкаф
2. Повесить шкаф.
У вас же написано, в основном, «Управлять молотком», «управлять отвёрткой», «управлять ключом».
-
ОК. Значит выходит нужно писать к примеру так: "Учесть рабочее время". Я так понимаю учет рабочего времени это же процесс, а процесс это и есть вариант использования.
-
Т.е. вот так:
-
Как-то так.
Я правда многого не понимаю.
Что такое «Оформить анкетирование персонала», например?
Я знаю, что есть подготовка анкетирования, проведение анкетирования, обработка результатов анкетирования, подготовка предложений по результатам анкетирования. Что именно у вас под «оформить»?
-
У меня должно быть все это сразу. Может "Провести работы по анектированию"?
-
Подниму тему, время идет платформа развивается, решения на 1С становятся все более глобальными а какой то культуры проектирования как не было так и нет.
К концу темы ушли от проектирования системы к описанию UC, в общем то у наших бизнес аналитиков нет проблем с описанием бизнеса, в основном используется ARIS. Получая от бизнес аналитиков схемы в общем то я ими доволен, и они помогают в работе (я ведущий разработчик).
Мои первоочередные задачи при проектировании системы, определить физическую модель данных:
1. Структуру хранения данных (Таблицы, состав полей).
2. Связи между таблицами.
Само по себе проектирование структуры хранения можно сделать и в конфигураторе, проблема в том что когда объектов конфигурации становится больше 30 - 40 да еще и большую часть создают другие люди то ориентироваться в конфигурации становится сложно, при этом средства по визуализации связей между объектами метаданных в 1С отсутствуют.
Т.е. для меня первоочередная задача это представление структуры БД.
Это в общем то несложная задача, в том же Visio можно создать Типы Справочник, РегистрСведений (хотя не совсем понятно как делать для этого типа виртуальную таблицу СрезПоследних), примерно так и происходит, но проблема в том что все это очень не удобно и времени на рисование схемы тратится очень много, плюс опять же опыта работы с UML нет, в книгах и курсах огромный объем информации причем я выделяю 2 типа:
1. Теория - сложно для понимания нужна для углубленного изучения когда уже есть понимание в принципе и требуется более детальное погружение.
2. Практические подходы с примерами - для быстрого изучения с последующим переходом к п1.
Книги обоих типов не сильно помогают в случае 1С т.к. в первом случае просто огромный поток информации который слабо пересекается с имеющимся опытом, во втором случае все очень сильно оторвано от особенностей платформы 1С.
т.е. для формирования культуры проектирования нужен человек у которого за плечами 3-4 года работы с UML и который хотя бы 2 года работал с 1С наверное только в этом случае получится применить UML для 1С.
Вот сейчас почитаю информацию которую предоставил Илья Федоров возможно что то для себя проясню, но даже начав читать я уже чувствую что информация правильно ложиться в голову т.к. новые для меня термины перемешаны с известными и читая я уже сразу понимаю как это использовать и какую проблему решает какое либо описание.
Понятно что в целом тема анализа и проектирования гораздо шире чем просто построение физической модели данных, но даже с такой малой частью не просто разобраться.
Если заглядывать дальше то у нас например есть еще одна проблема, наши бизнес аналитики предоставляют результаты в терминах "бизнеса" т.е. выполнил платеж, проверил оплату, отгрузил партию, ввел данные, распечатал накладную и.т.п.
На мой взгляд между аналитиками разработчиками не хватает еще одного звена, который данные бизнес аналитиков приведет к терминам "конфигурации" т.е. заполнил форму, провел документ, документ выполнил проверки и сделал движения по регистрам.
Но собственно наши бизнес аналитики про 1С знают очень слабо а на курсах и вообще в "тусовке" про 1С знают и того меньше поэтому этот этап обычно пропускается из за чего в дальнейшем приходится или костылить или переписывать части конфигурации.
-
Да, если что про СППР мы в курсе, пытаемся использовать, но по факту польза от нее только для генерации документации, и как то так получается что в основном заносим информацию в СППР уже по готовому решению, т.к. весь интерфейс и принцип работы не предполагает что проектирование ведется в СППР, т.к. пока ту же функцию внесешь забудешь несколько раз про то что дальше хотел делать, поэтому получается так что сначала все на листочках спроектировал в конфигураторе оформил и только потом внес в СППР. Т.е. для описания конфигурации решение СППР в целом пригодно, для проектирования частично пригодно т.к. средства визуализации не далеко ушли от того же конфигуратора.
-
Если вопрос только в модели данных и ответить кратко, то в UML имеет смысл фиксировать только бизнес-объекты и их связи (это может делать аналитик). Для более детального проектирования данных для 1С UML непригоден.