Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Alllie, Вы писали:
A>>А напишите мысли про такие комбинации. A>>Бухгалтерский учет + магазин. A>>Бухгалтерский учет + склад. A>>Бухгалтерский учет + магазин + склад. A>>+ взаимодействие между магазином и складом. A>Я в таких случах люблю говорю "возможно все", вся соль в сложности и стоимости этого решения. A>Если склад и магазин независимы, то все просто, а если складу и магазину нужно взаимодействовать друг с другом, то тут либо не разделять их совсем, либо городить сверху канал взаимодействия меду ними, в том числе и для случая, когда склад магазину не нужен или наоборот.
A>>Хотя в данном контексте я бы добавил товары, склад сделал бы как хранилище товаров, магазин тоже как хранилище товаров + с изменения в бухгалтерском учете. A>Хранилице товаров у нас уже есть, это склад. Зачем делать второй склад в магазине? A>Магазин это цены, операции купли продажи, скидки, покупатели, ... A>Склад в этом случае может работаь без магазина, магазин без склада уже никак. Можно сделать магазин с внутренним складом (складом, но попроще), тогда магазин будет работать один, без склада. A>Склад, кстати, это не только какого и сколько товара есть (это то что нужно магазину). Но и то где товар лежит, когда его привезли, кто привез, еще есть операции -- приемка, отгрузка, списание, хранение, ...
A>Короч, все зависит от задач, которые система рашает, а не от того что мы с тобой напридумываем. A>Опиши задачи системы и будем разговаривать, придумывать варианты использования теоретических конструкций как-то не хочется. Хотя жизнь такая штука, что любая, даже бредовая, комбинация в ней возможна.
A>>В итоге получается, что ядро обладает бухгалтерским учетом + товарами + интерфесом хранилища товаров, а модули это реализация интерфейса хранилища. То есть опять же модули расширяют основное ядро, которое уже в себе имеет возможные варианты бизнес процессов и данных с которыми работает ПО. A>Не знаю, все будет упираться в задачи.
A>СУВ, Aikin
Я принципе сформировал определённое мнение, благодаря участникам дискуссии, думаю дальше нужно просто реализовать один из вариантов.
Если у кого будут ссылки на модульные программы с открытыми исходниками, кидайте, буду благодарен.
Здравствуйте, Alllie, Вы писали:
A>Здравствуйте, samius, Вы писали:
A>Согласен, что определения не супер. A>Давайте на примере: A>ПО для пользователя, который ведет свой быт. A>Первый модуль (обязательный) — учет денег.
Отлично. Но нет смысла учитывать деньги безотносительно всего, в том числе статей доходов, расходов.
A>Второй модуль (не обязательный) — машины. Пользователь купил машину, добавил модуль. Там он ввел, ремонт машины 5000 рублей. И в модуле учета денег, снялись деньги.
С точки зрения ПО покупка машины вряд ли сильно отличается от покупки хлеба. Потому я не вижу необходимости помещения машины и хлеба в различные компоненты. Для учета денег нам вообще не нужны модели предметов "машина", "хлеб".
То есть добавляя модуль, связанный с учетом статей расходов на тему машин, вы не расширяете предметную область, вы просто пополняете базу предопределенных статей расходов.
A>Третий модуль (не обязательный) — бизнес. Пользователь открыл бизнес. Отметил затраты, они высветились в модуле учета денег. Пользователь, если есть модуль "машины" может записать машину в капитал бизнеса.
С бизнесом в общем случае интереснее, но в вашей задаче фигурируют лишь "затраты". А что это как не дополнительные статьи расходов в рамках базовой функциональности по учету денег?
Вот если бы вы добавили новые операции, инструменты для отчетности, анализа, планирования, то можно было бы говорить о расширении.
A>Пример опять же спорный, но суть думаю ясна.
Я не увидел в вашем примере расширения предметной области "учет денег".
A>И помоему 1С модульная. Модуль компании, склад и т.д.
Вполне.
Здравствуйте, Alllie, Вы писали:
A>Слабо описал. Отдельный модуль машина нужен, что бы вести всю информацию по машине. Страховка, купить новые колеса, заменить масло, поменять бампер, съездить на ТО такого то числа. С модулем "бизнес" так же. Нанять персонал (внутренний модуль персонал), купить компы для персонала, съездить в налоговую, отправить документы партнерам, отправить товар клиентам и т.п.
Ну вот смотри (результат 3х минут обдумывания):
Компоненты:
1) Ядро системы: компонент учета затрат (купить, заплатить, ...), компонент учета задач (задачи, расписание, уведомления)
2) "Плагины": компонент "машина", компонент "бизнес"...
ядро + Машина -- вполне работоспособная система. Может это как раз то, что имел заказчик?
Из ядра обычно ничего вы убирают, но "ядерные плагины" тоже могут быть (плагин, который рассылает уведомления в jabber).
Здравствуйте, Alllie, Вы писали:
A>>Хороший пример про "Пример, система состоит из 3х компонент: склад, магазин, бухгалтерский учет. Компоненты Магазин или Склад вполне могут использоваться отдельно." А напишите мысли про такие комбинации. A>>Бухгалтерский учет + магазин. A>>Бухгалтерский учет + склад. A>>Бухгалтерский учет + магазин + склад. A>>+ взаимодействие между магазином и складом. A>>Хотя в данном контексте я бы добавил товары, склад сделал бы как хранилище товаров, магазин тоже как хранилище товаров + с изменения в бухгалтерском учете. В итоге получается, что ядро обладает бухгалтерским учетом + товарами + интерфесом хранилища товаров, а модули это реализация интерфейса хранилища. То есть опять же модули расширяют основное ядро, которое уже в себе имеет возможные варианты бизнес процессов и данных с которыми работает ПО.
A>В продолжение, такая мысль. Инкапсуляция данных в модулях или в ядре.
Предлагаю отталкиваться от задач, которые необходимо решить, а не от того, где располагать данные. Задачи первичны, данные нужны для их решения.
A>Магазин ничего не знает о модуле статистики. Модуль статистики зависит от модуля магазин. Когда формируется отчет модуль статистики обращается к модулю магазин, что бы получить список товаров, список клиентов и т.п. Если добавить модуль склад, то модуль статистики будет полностью зависеть и от него, плюс нужно разбираться, как из модуля склад будут передаваться товары в модуль магазин и наоборот (при условии, что каждый из них должен оперировать товарами). То есть появляются жесткие зависимости и возможно Circular Dependencies.
Вы как-то оперируете большими понятиями "магазин", "склад", "статистика", не уточняя задачи, которые должны быть решены. Статистика — это вообще говоря раздел науки и я не представляю как написать универсальный модуль, который бы можно было прицепить и к магазину и к складу и к венерическим заболеваниям. Хоть статистика — она одна, но в случае склада и магазина статистика призвана решать разные пользовательские задачи. Это модуль логирования можно один на все замутить.
Я понимаю что клиент возможно собирается продавать модули (магазин, склад, статистика) за отдельные деньги. Но статистика магазина и статистика склада в общем случае — разные вещи. Без уточнения конкретных величин вряд ли можно собрать один модуль. Т.е. по факту скорее всего получится магазин + статистика магазина, склад + статистика склада и отдельно статистика магазина и склада (для случаев когда мы хотим максимизировать прибыль в условиях ограниченного склада при отсутствии данных об объемах упаковки товара в магазине и отсутствии данных об отпускной цене на складе).
Определения: Компонент (Component). Предоставляет интерфейс. Реализует собственную или расширяет (изменяет) имеющуюся предметную область. Полностью зависит от окружения. Может зависеть от других компонентов. Окружение (Environment). Разновидность компонента. Система, реализующая определенную предметную область и позволяющая интегрировать в нее компоненты. Обеспечивает взаимодействие компонентов. Примеры: OS, Framework, Application. Зависимость (Dependence). Отсутствие возможности использовать компонент без компонента, от которого он зависит. Взаимодействие (Communication). Вызов одного компонента другим. Интерфейс (Interface). Декларация взаимодействия. Протокол (Protocol). Разновидность интерфейса, через который взаимодействуют компоненты. Предметная область (Domain). Определяет совокупность данных и действий над данными, объединенных определенным признаком. Данные компонента (Component data). Данные, которыми оперирует компонент.
Типы компонентов: Плагин (Plugin).http://en.wikipedia.org/wiki/Plug-in_(computing) Не имеет своей предметной области. Расширяет предметную область окружения. От него не зависят другие компоненты. Оперирует данными окружения. Модуль (Module).://en.wikipedia.org/wiki/Software_extension Имеет свою предметную область, инкапсулирует ее данные в себя. Может зависеть от других модулей, может взаимодействовать с другими модулями.
Примеры разделения системы на компоненты: OS. OS – окружение. Приложение – компонент. Application layers. На сайте msdn предлагается разделять приложение на компоненты по слоям (функциональным предметным областям). Компонент доступа к БД Data Access Layer, Компонент пользовательского интерфейса User Interface Layer и т.п. В данном случае UIL жестко завязан на DAL. Joomla. Components: The largest and most complex extensions of them all; they can be seen as mini-applications. Most components have two parts: a site part and an administrator part. Every time a Joomla page loads, one component is called to render the main page body. Components are the major portion of a page because a component is driven by a menu item and every menu item runs a component.
Plugins: These are more advanced extensions and are, in essence, event handlers. In the execution of any part of Joomla, a module or a component, an event can be triggered. When an event is triggered, plugins that are registered with the application to handle that event execute. For example, a plugin could be used to block user-submitted articles and filter out bad words.
Templates: Describe the main design of the Joomla website and are the extensions that allow users to change the look of the site. Users will see modules and components on a template. They are customizable and flexible. Templates determine the “style” of a website.
Modules: Rendering pages flexibly in Joomla requires a module extension, which is then linked to Joomla components to display new content or new images. Joomla modules look like boxes – like the “search” or “login” module. However, they don’t require html to Joomla to work.
Languages: Very simple extensions that can either be used as a core part or as an extension. Language and font information can also be used for PDF or PSD to Joomla conversions. SOA. Cервисы – модули, компоненты с независимыми предметными областями. Взаимодействие через шину, в которую публикуются сообщения. Вопрос №1: в каком случае можно разделить связанные предметные области, на отдельные компоненты инкапсулирующие части всей предметной области, без сильных зависимостей. Что бы в дальнейшем можно было убрать компонент, но ПО продолжало функционировать. Вопрос №2: Покритикуете следующие архитектуры ПО и предложите свои. Плагинная архитектура: вся предметная область реализована в окружении, плагины изменяют существующий функционал. Пример: ПО для работы с прайс-листами, является окружением, позволяет создавать плагины для экспорта/ импорта информации, плагин реализует импорт/экспорт в определенный формат файла. Модульная архитектура: часть предметной области реализована в окружении, так же в окружении реализовано взаимодействие модулей, есть обязательные модули, есть не обязательные. Приведите пример. Вопрос №3: приведите примеры архитектуры с расширяемой предметной областью. Вопрос №4: приведите примеры способов слабого связывания и взаимодействия компонентов, реализующих связанные предметные области.
Здравствуйте, Alllie, Вы писали:
A>Определения: A>Протокол (Protocol). Разновидность интерфейса, через который взаимодействуют компоненты.
Протокол — это имхо описание последовательности (возможных последовательностей) действий с неким набором компонентов, которая (последовательность) приводит к искомому результату.
Здравствуйте, Marty, Вы писали:
M>Протокол — это имхо описание последовательности (возможных последовательностей) действий с неким набором компонентов, которая (последовательность) приводит к искомому результату.
Судя по вопросам, это лабоработка. Так что тут спорить бесполезно.
СУВ, Aikin
P.S. Топикстартеру: чтобы люди охотнее отвечали на вопросы, дай свои варианты ответов -- получишь кучу коментариев к ним, их которых уже можно будет выудить ответ.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Marty, Вы писали:
M>>Протокол — это имхо описание последовательности (возможных последовательностей) действий с неким набором компонентов, которая (последовательность) приводит к искомому результату. A>Судя по вопросам, это лабоработка. Так что тут спорить бесполезно.
A>СУВ, Aikin
A>P.S. Топикстартеру: чтобы люди охотнее отвечали на вопросы, дай свои варианты ответов -- получишь кучу коментариев к ним, их которых уже можно будет выудить ответ.
Это не лабораторная работа. Работаю программистом, возник вопрос по модульности ПО. Определения написал от себя для того, что бы вопросы были более понятными. Примеры привел тоже для понятности.
Есть некое ТЗ, которое описывает SOA архитектуру, в ней выделены ряд сервисов и написано, что бы из системы можно было убрать часть сервисов и она продолжала функционировать. После более точного взгляда на сервисы пришел к выводу, что разделить их и убрать скорее всего не получится, да и разделение это особо не целесообразно, так как все сервисы описывают части одной предметной области. То есть возможно ТЗ изначально неправильно составлено, так как требуют SOA, а в определении SOA, каждый сервис это атомарная единица, для которой можно сделать даже отдельно хранилище данных (своя отдельная БД).
А так я считаю, что SOA, это то же самое, что обычное ПО, просто компонентами выступают сервисы, то хотелось бы разобраться в создании модульного ПО. Почитал статьи на Wikipedia. https://en.wikipedia.org/wiki/Modular_programming https://en.wikipedia.org/wiki/Separation_of_concerns https://en.wikipedia.org/wiki/Component-based_software_engineering https://en.wikipedia.org/wiki/Normalized_Systems
В статьях довольно отдаленно все описывает, но без более менее конкретных примеров реализации.
Про плагины, модули, окружение, предметную область, это то как на данный момент я представляю себе написание модульного ПО.
Если считать, что с плагинами более менее понятно, то хотелось бы, что бы вы привели пример модульных систем, в которых вся предметная область разделена на модули. Такое вообще существует? Как это соотносится с бизнес процессами, может быть система, в которой есть минимальное количество бизнес процессов, реализованных определенными модулями и добавление новых модулей, которые будут расширять и изменять существующие бизнес процессы.
Здравствуйте, Alllie, Вы писали:
A>Это не лабораторная работа. Работаю программистом, возник вопрос по модульности ПО. Определения написал от себя для того, что бы вопросы были более понятными. Примеры привел тоже для понятности.
Сорри, но уж больно смахивает: цель отсутствует, а вариантов ответа 100500.
A>Есть некое ТЗ, которое описывает SOA архитектуру, в ней выделены ряд сервисов и написано, что бы из системы можно было убрать часть сервисов и она A>После более точного взгляда на сервисы пришел к выводу, что разделить их и убрать скорее всего не получится, да и разделение это особо не целесообразно, так как все сервисы описывают части одной предметной области. То есть возможно ТЗ изначально неправильно составлено, так как требуют SOA, а в определении SOA, каждый сервис это атомарная единица, для которой можно сделать даже отдельно хранилище данных (своя отдельная БД).
Такие вопросы обычно решают аналитики, а не девелоперы. Все что девелоперы могут тут сделать, это доказать что заказчик дебил. Зачем начинать с этого работу?
Пусть аналитики разузнают что же имел ввиду под этим заказчик. Удивишься, но окажется что имел ввиду от вполне осмысленную штуку (и совсем не то, что ты себе представляешь).
A>В статьях довольно отдаленно все описывает, но без более менее конкретных примеров реализации. A>Про плагины, модули, окружение, предметную область, это то как на данный момент я представляю себе написание модульного ПО.
A>Если считать, что с плагинами более менее понятно, то хотелось бы, что бы вы привели пример модульных систем, в которых вся предметная область разделена на модули. Такое вообще существует? Как это соотносится с бизнес процессами, может быть система, в которой есть минимальное количество бизнес процессов, реализованных определенными модулями и добавление новых модулей, которые будут расширять и изменять существующие бизнес процессы.
Не вижу как это поможет в обзвученной проблеме.
Здравствуйте, Aikin, Вы писали:
A>Такие вопросы обычно решают аналитики, а не девелоперы. Все что девелоперы могут тут сделать, это доказать что заказчик дебил. Зачем начинать с этого работу? A>Пусть аналитики разузнают что же имел ввиду под этим заказчик. Удивишься, но окажется что имел ввиду от вполне осмысленную штуку (и совсем не то, что ты себе представляешь).
Если же аналитиков нет и общатся с заказчиком придется тебе, то я бы на твоем месте так бы и скзаал (личная встреча, телефоный разговор, переписка) "нам не понятны некоторые моменты в ТЗ".
Раз ты ты смог написать все определения в первом посте, то и предметно поговорить с заказчиком вполне сможешь, и "не ударишь лицом в грязь".
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Aikin, Вы писали:
A>>Такие вопросы обычно решают аналитики, а не девелоперы. Все что девелоперы могут тут сделать, это доказать что заказчик дебил. Зачем начинать с этого работу? A>>Пусть аналитики разузнают что же имел ввиду под этим заказчик. Удивишься, но окажется что имел ввиду от вполне осмысленную штуку (и совсем не то, что ты себе представляешь). A>Если же аналитиков нет и общатся с заказчиком придется тебе, то я бы на твоем месте так бы и скзаал (личная встреча, телефоный разговор, переписка) "нам не понятны некоторые моменты в ТЗ". A>Раз ты ты смог написать все определения в первом посте, то и предметно поговорить с заказчиком вполне сможешь, и "не ударишь лицом в грязь".
A>СУВ, Aikin
То есть вы согласны с моей точкой зрения на ситуацию, про ТЗ, про SOA? Просто я даже в этом не был уверен, не умею я разговаривать с людьми и доказывать точку зрения в которой не уверен, если бы прочитал пару статей в интернете, то был бы больше уверен, чем на собственно придуманных определениях и примерах. То есть хочется ссылки на статью, где написано "нельзя одну предметную область разместить в разных компонентах и убирать эти компоненты, когда хочется".
И я не просто в первом посте не описывал ТЗ, так как ТЗ, это конкретный случай. А я хочу разобраться в вопросе написания модульного ПО.
Здравствуйте, Alllie, Вы писали:
A>То есть вы согласны с моей точкой зрения на ситуацию, про ТЗ, про SOA? Просто я даже в этом не был уверен, не умею я разговаривать с людьми и доказывать точку зрения в которой не уверен, если бы прочитал пару статей в интернете, то был бы больше уверен, чем на собственно придуманных определениях и примерах. То есть хочется ссылки на статью, где написано "нельзя одну предметную область разместить в разных компонентах и убирать эти компоненты, когда хочется".
Откуда вообще этот тезис взялся про размещение предметной области в разных компонентах и убирания их? Может проблема в определениях?
Предметная область (Domain). Определяет совокупность данных и действий над данными, объединенных определенным признаком.
Вообще-говоря, фигня, а не определение.
Раз уж вы берете что-то из википедии, то берите смелее и все остальное. В том числе предметную область, SOA, компоненты и т.п.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Alllie, Вы писали:
A>>То есть вы согласны с моей точкой зрения на ситуацию, про ТЗ, про SOA? Просто я даже в этом не был уверен, не умею я разговаривать с людьми и доказывать точку зрения в которой не уверен, если бы прочитал пару статей в интернете, то был бы больше уверен, чем на собственно придуманных определениях и примерах. То есть хочется ссылки на статью, где написано "нельзя одну предметную область разместить в разных компонентах и убирать эти компоненты, когда хочется". S>Откуда вообще этот тезис взялся про размещение предметной области в разных компонентах и убирания их? Может проблема в определениях? S>
S>Предметная область (Domain). Определяет совокупность данных и действий над данными, объединенных определенным признаком.
S>Вообще-говоря, фигня, а не определение. S>Раз уж вы берете что-то из википедии, то берите смелее и все остальное. В том числе предметную область, SOA, компоненты и т.п.
Согласен, что определения не супер.
Давайте на примере:
ПО для пользователя, который ведет свой быт.
Первый модуль (обязательный) — учет денег.
Второй модуль (не обязательный) — машины. Пользователь купил машину, добавил модуль. Там он ввел, ремонт машины 5000 рублей. И в модуле учета денег, снялись деньги.
Третий модуль (не обязательный) — бизнес. Пользователь открыл бизнес. Отметил затраты, они высветились в модуле учета денег. Пользователь, если есть модуль "машины" может записать машину в капитал бизнеса.
Пример опять же спорный, но суть думаю ясна.
И помоему 1С модульная. Модуль компании, склад и т.д.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Alllie, Вы писали:
A>>Здравствуйте, samius, Вы писали:
A>>Согласен, что определения не супер. A>>Давайте на примере: A>>ПО для пользователя, который ведет свой быт. A>>Первый модуль (обязательный) — учет денег. S>Отлично. Но нет смысла учитывать деньги безотносительно всего, в том числе статей доходов, расходов.
A>>Второй модуль (не обязательный) — машины. Пользователь купил машину, добавил модуль. Там он ввел, ремонт машины 5000 рублей. И в модуле учета денег, снялись деньги. S>С точки зрения ПО покупка машины вряд ли сильно отличается от покупки хлеба. Потому я не вижу необходимости помещения машины и хлеба в различные компоненты. Для учета денег нам вообще не нужны модели предметов "машина", "хлеб". S>То есть добавляя модуль, связанный с учетом статей расходов на тему машин, вы не расширяете предметную область, вы просто пополняете базу предопределенных статей расходов.
A>>Третий модуль (не обязательный) — бизнес. Пользователь открыл бизнес. Отметил затраты, они высветились в модуле учета денег. Пользователь, если есть модуль "машины" может записать машину в капитал бизнеса. S>С бизнесом в общем случае интереснее, но в вашей задаче фигурируют лишь "затраты". А что это как не дополнительные статьи расходов в рамках базовой функциональности по учету денег? S>Вот если бы вы добавили новые операции, инструменты для отчетности, анализа, планирования, то можно было бы говорить о расширении.
A>>Пример опять же спорный, но суть думаю ясна. S>Я не увидел в вашем примере расширения предметной области "учет денег".
A>>И помоему 1С модульная. Модуль компании, склад и т.д. S>Вполне.
Слабо описал. Отдельный модуль машина нужен, что бы вести всю информацию по машине. Страховка, купить новые колеса, заменить масло, поменять бампер, съездить на ТО такого то числа. С модулем "бизнес" так же. Нанять персонал (внутренний модуль персонал), купить компы для персонала, съездить в налоговую, отправить документы партнерам, отправить товар клиентам и т.п.
Здравствуйте, Alllie, Вы писали:
A>>Раз ты ты смог написать все определения в первом посте, то и предметно поговорить с заказчиком вполне сможешь, и "не ударишь лицом в грязь". A>То есть вы согласны с моей точкой зрения на ситуацию, про ТЗ, про SOA?
Неа, я не вдавался в детали. Вижу, что явнях косяков в определениях нет, вопросы тоже нормальные. Сделал вывод, что ты в предмете разбираешься.
Про ТЗ вообще ничего сказатьне могу. Ты написал свое видение того, что написано в ТЗ. В ТЗ вполне может быть совсем другое написано (а заказчик имел ввиду третье).
A> Просто я даже в этом не был уверен, не умею я разговаривать с людьми и доказывать точку зрения в которой не уверен, если бы прочитал пару статей в интернете, то был бы больше уверен, чем на собственно придуманных определениях и примерах.
Я уже говорил: не нужно пытаться доказать что заказчик "дурак", нужно честно скзать: мы не понимаем, что вы здесь имели ввиду. Не могли бы вы разяснить.
Можно прямо спросить "какие компоненты вы планируете использовать отдельно от других?". Вы не доказываете, вы разбираетесь.
Лучше сейчас задать "глупый" вопрос, чем потом кусать локти, когда система наполовину написана.
A>То есть хочется ссылки на статью, где написано "нельзя одну предметную область разместить в разных компонентах и убирать эти компоненты, когда хочется".
Не будет такой статьи. Потому как я не вижу тут нчего принципиально невозможного.
Пример, система состоит из 3х компонент: склад, магазин, бухгалтерский учет. Компоненты Магазин или Склад вполне могут использоваться отдельно.
Здравствуйте, Alllie, Вы писали:
A>Здравствуйте, samius, Вы писали:
A>>>Пример опять же спорный, но суть думаю ясна. S>>Я не увидел в вашем примере расширения предметной области "учет денег".
A>>>И помоему 1С модульная. Модуль компании, склад и т.д. S>>Вполне.
A>Слабо описал. Отдельный модуль машина нужен, что бы вести всю информацию по машине. Страховка, купить новые колеса, заменить масло, поменять бампер, съездить на ТО такого то числа. С модулем "бизнес" так же. Нанять персонал (внутренний модуль персонал), купить компы для персонала, съездить в налоговую, отправить документы партнерам, отправить товар клиентам и т.п.
Вот, снова. Без описания предметной области базового модуля сложно говорить о расширении предметной области в других. Если базовый умеет заниматься планированием (предположим) "Хлеб, купить яйца, заменить видеокассету в прокате, пройти медосмотр", то что нового кроме названий операций и расходов вносит модуль "машина" или "бизнес"?
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, Alllie, Вы писали:
A>>>Раз ты ты смог написать все определения в первом посте, то и предметно поговорить с заказчиком вполне сможешь, и "не ударишь лицом в грязь". A>>То есть вы согласны с моей точкой зрения на ситуацию, про ТЗ, про SOA? A>Неа, я не вдавался в детали. Вижу, что явнях косяков в определениях нет, вопросы тоже нормальные. Сделал вывод, что ты в предмете разбираешься. A>Про ТЗ вообще ничего сказатьне могу. Ты написал свое видение того, что написано в ТЗ. В ТЗ вполне может быть совсем другое написано (а заказчик имел ввиду третье).
A>> Просто я даже в этом не был уверен, не умею я разговаривать с людьми и доказывать точку зрения в которой не уверен, если бы прочитал пару статей в интернете, то был бы больше уверен, чем на собственно придуманных определениях и примерах. A>Я уже говорил: не нужно пытаться доказать что заказчик "дурак", нужно честно скзать: мы не понимаем, что вы здесь имели ввиду. Не могли бы вы разяснить. A>Можно прямо спросить "какие компоненты вы планируете использовать отдельно от других?". Вы не доказываете, вы разбираетесь.
A>Лучше сейчас задать "глупый" вопрос, чем потом кусать локти, когда система наполовину написана.
A>>То есть хочется ссылки на статью, где написано "нельзя одну предметную область разместить в разных компонентах и убирать эти компоненты, когда хочется". A>Не будет такой статьи. Потому как я не вижу тут нчего принципиально невозможного. A>Пример, система состоит из 3х компонент: склад, магазин, бухгалтерский учет. Компоненты Магазин или Склад вполне могут использоваться отдельно.
A>СУВ, Aikin
Про конкретный случай с ТЗ я понял, спасибо за совет.
Хороший пример про "Пример, система состоит из 3х компонент: склад, магазин, бухгалтерский учет. Компоненты Магазин или Склад вполне могут использоваться отдельно." А напишите мысли про такие комбинации.
Бухгалтерский учет + магазин.
Бухгалтерский учет + склад.
Бухгалтерский учет + магазин + склад.
+ взаимодействие между магазином и складом.
Хотя в данном контексте я бы добавил товары, склад сделал бы как хранилище товаров, магазин тоже как хранилище товаров + с изменения в бухгалтерском учете. В итоге получается, что ядро обладает бухгалтерским учетом + товарами + интерфесом хранилища товаров, а модули это реализация интерфейса хранилища. То есть опять же модули расширяют основное ядро, которое уже в себе имеет возможные варианты бизнес процессов и данных с которыми работает ПО.
A>Хороший пример про "Пример, система состоит из 3х компонент: склад, магазин, бухгалтерский учет. Компоненты Магазин или Склад вполне могут использоваться отдельно." А напишите мысли про такие комбинации. A>Бухгалтерский учет + магазин. A>Бухгалтерский учет + склад. A>Бухгалтерский учет + магазин + склад. A>+ взаимодействие между магазином и складом. A>Хотя в данном контексте я бы добавил товары, склад сделал бы как хранилище товаров, магазин тоже как хранилище товаров + с изменения в бухгалтерском учете. В итоге получается, что ядро обладает бухгалтерским учетом + товарами + интерфесом хранилища товаров, а модули это реализация интерфейса хранилища. То есть опять же модули расширяют основное ядро, которое уже в себе имеет возможные варианты бизнес процессов и данных с которыми работает ПО.
В продолжение, такая мысль. Инкапсуляция данных в модулях или в ядре.
Система А. Модули инкапсулируют, только те данные, которые не нужны другим модулям. Данные, которые нужны нескольким модулям выносятся в ядро.
Ядро
— Бухгалтерский учет
— Товары
— Интерфейс хранилища
Модули
— Магазин
— Склад
Магазин ничего не знает о складе, склад ничего не знает о магазине, все основное в ядре, если нужно расширить функционал, то надо расширять ядро.
Система Б. Модули инкапсулируют данные с которыми работают. Магазин инкапсулирует данные о товарах и клиентах.
Ядро
— Бухгалтерский учет
Модули
— Магазин
— Модуль статистики
Магазин ничего не знает о модуле статистики. Модуль статистики зависит от модуля магазин. Когда формируется отчет модуль статистики обращается к модулю магазин, что бы получить список товаров, список клиентов и т.п. Если добавить модуль склад, то модуль статистики будет полностью зависеть и от него, плюс нужно разбираться, как из модуля склад будут передаваться товары в модуль магазин и наоборот (при условии, что каждый из них должен оперировать товарами). То есть появляются жесткие зависимости и возможно Circular Dependencies.
Здравствуйте, Alllie, Вы писали:
A>А напишите мысли про такие комбинации. A>Бухгалтерский учет + магазин. A>Бухгалтерский учет + склад. A>Бухгалтерский учет + магазин + склад. A>+ взаимодействие между магазином и складом.
Я в таких случах люблю говорю "возможно все", вся соль в сложности и стоимости этого решения.
Если склад и магазин независимы, то все просто, а если складу и магазину нужно взаимодействовать друг с другом, то тут либо не разделять их совсем, либо городить сверху канал взаимодействия меду ними, в том числе и для случая, когда склад магазину не нужен или наоборот.
A>Хотя в данном контексте я бы добавил товары, склад сделал бы как хранилище товаров, магазин тоже как хранилище товаров + с изменения в бухгалтерском учете.
Хранилице товаров у нас уже есть, это склад. Зачем делать второй склад в магазине?
Магазин это цены, операции купли продажи, скидки, покупатели, ...
Склад в этом случае может работаь без магазина, магазин без склада уже никак. Можно сделать магазин с внутренним складом (складом, но попроще), тогда магазин будет работать один, без склада.
Склад, кстати, это не только какого и сколько товара есть (это то что нужно магазину). Но и то где товар лежит, когда его привезли, кто привез, еще есть операции -- приемка, отгрузка, списание, хранение, ...
Короч, все зависит от задач, которые система рашает, а не от того что мы с тобой напридумываем.
Опиши задачи системы и будем разговаривать, придумывать варианты использования теоретических конструкций как-то не хочется. Хотя жизнь такая штука, что любая, даже бредовая, комбинация в ней возможна.
A>В итоге получается, что ядро обладает бухгалтерским учетом + товарами + интерфесом хранилища товаров, а модули это реализация интерфейса хранилища. То есть опять же модули расширяют основное ядро, которое уже в себе имеет возможные варианты бизнес процессов и данных с которыми работает ПО.
Не знаю, все будет упираться в задачи.
Рискну предположить с какой проблемой столкнулся автор. Повествование буду вести не в рамках его терминологической системы.
Есть известная пара Document — View. Document — данные и бизнес логика. View — это UI представление данных и бизнес логики. Так вот компоненты уровня Document это не тоже самое что компоненты уровня View, хотя между ними есть определенная связь. Грубо говоря компоненты уровня Document это модули (множества классов). Компоненты уровня View это некоторые UI компоненты или плагины.
Предположим в ТЗ нас просят реализовать набор функциональности Бухгалтерия и Учет Транспортных средств. В Бухгалтерии мы можем просто вести учет денег. А в Учет Транспортных средств мы можем купить машину и сделать связанную проводку в Бухгалтерия. Бухгалтерия может продаваться без Учет Транспортных средств. Но у Учет Транспортных средств не может продаваться без Бухгалтерия.
Выделяем два компонента уровня Document: Document_Бухгалтерия и Document_Учет_транспортных_средств. Document_Учет_транспортных_средств зависит от Document_Бухгалтерия. Document_Бухгалтерия может работать без Document_Учет_транспортных_средств. Но Document_Учет_транспортных_средств не может работать без Document_Бухгалтерия.
Теперь посмотрим что будет на уровне View. У нас будет два компонента: View_Бухгалтерия и View_Учет_транспортных_средств. View_Учет_транспортных_средств также зависит от View_Бухгалтерия. Но хотим ли мы видеть в View_Бухгалтерия финансовые операции с привязкой к транспортирным средствам. Да хотим. Само собой в View_Учет_транспортных_средств мы хотим видеть финансовые операции с каждым транспортным средством. То есть здесь зависимость уже двунаправленная. Как это реализовать? Нужен плагин функциональности Учет_транспортных_средств к Бухгалтерия. То есть на уровне View уже 3 компонента.
А если заказчик еще хочет продавать Учет Транспортных средств без Бухгалтерия? Ну купил авто, а на деньги наплевать. Тогда все усложняется. На уровне Document компоненты Document_Бухгалтерия и Document_Учет_транспортных_средств становятся независимыми. И появляется третий Document компонент, который будет обеспечивать взаимодействие Document_Бухгалтерия и Document_Учет_транспортных_средств. На уровне View компоненты View_Учет_транспортных_средств и View_Учет_транспортных_средств также становятся независимыми. И появляется четвертый View компонент: плагин бухгалтерии к транспортным средствам.
Мне кажется автор смешивает три разных вещи:
набор функциональных подсистем, которые требуются по ТЗ
компоненты уровня Document
компоненты уровня View
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
порекомендую посмотреть спецификации OSGi http://en.wikipedia.org/wiki/OSGi, Eclipse ей следует.
интересная книжка по архитектуре опенсорсных программ "The Architecture of Open Source Applications" Amy Brown and Greg Wilson
