Нужен совет по ООП и UML
От: SPeller  
Дата: 19.09.10 04:18
Оценка:
Всем здравствуйте!

Помогите решить задачу:

Существуют документы: счет и накладная.

Счет имеет следующие атрибуты:
• дата счета;
• номер счета;
• сумма счета;
• поставщик.
В табличной части содержатся товары.
Атрибуты товара:
• наименование товара:
• производитель;
• цена;
• количество.

Накладная имеет атрибуты:
• дата;
• номер;
• сумма по накладной;
• грузоотправитель;
• номер счета.
В табличной части содержатся товары (товары могут отличаться).
Атрибуты товара:
• наименование товара;
• производитель;
• серия;
• цена;
• количество.

Предусмотреть проверки:
1. Введенная дата счета не больше текущей даты;
2. Введенная дата накладной не больше даты счета и не больше текущей даты;
3. При сохранении документов табличная часть не должна быть пустой;
4. При редактировании накладной не можем изменять поле грузоотправитель.

Требуется спроектировать предложенные сущности в нотации UML, создав диаграмму классов, и реализовать классы на любом языке программирования.
При проектировании обязательно использовать паттерны ООП (MVC, Factory, Singleton и т.д.).


На вот такой вариант решения: http://personal.primorye.ru/speller/Drawing1.gif получил такой ответ:

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

Вопрос: что еще нужно доделать в моей диаграмме? Подсказывали мне что нужно подробнее развернуть слой Представление, но куда и как — плохо понимаю. Подскажите пожалуйста.
Re: Нужен совет по ООП и UML
От: sereginseregin Россия http://daremanager.sourceforge.net/ru/
Дата: 20.09.10 05:45
Оценка:
Здравствуйте, SPeller, Вы писали:

SP>... подробнее развернуть слой Представление, но куда и как — плохо понимаю. Подскажите пожалуйста.

А на что у Вас на картинке прямоугольник с надписью "Интерфейс пользователя" — вот его и разверните для каждой сущности.

Хочу еще добавить:
1. ИМХО, Ваш подход, когда один контролер для нескольких документов на практике не масштабируем. На Ваши 2 документа вы описали 10 функций, соответственно на 100-200 документов будет около 2000 функций. Рассмотрите Вашу идеологию MVC отдельно для каждого документа и затем объедините полученные модели минимальными связями.

2. Ваши проверки:
SP>1. Введенная дата счета не больше текущей даты;
SP>2. Введенная дата накладной не больше даты счета и не больше текущей даты;
SP>3. При сохранении документов табличная часть не должна быть пустой;
SP>4. При редактировании накладной не можем изменять поле грузоотправитель.
на практике также не имеют особого смысла. Хозяйственные операции между продавцом и покупателем ведутся в договорной форме, сделка может быть сложной и проходить в длинный промежуток времени, счета и накладные могут многократно перевыставляться. Наше хаконодательство несовершенно, придумывать свои ограничения, даже если они кажутся логичными — это вставлять палки Бухгалтеру. Для начала рассмотрите только те ограничения, которые требуются законодательно, например в Положениях по бухгалтерскому учету (ПБУ), остальное бухгалтер проконтролирует сам, или даст замечания на доработку.
Re[2]: Нужен совет по ООП и UML
От: SPeller  
Дата: 20.09.10 06:29
Оценка:
Здравствуйте, sereginseregin, Вы писали:

SP>>... подробнее развернуть слой Представление, но куда и как — плохо понимаю. Подскажите пожалуйста.

S>А на что у Вас на картинке прямоугольник с надписью "Интерфейс пользователя" — вот его и разверните для каждой сущности.
Вот это до меня и не доходит пока Что именно описывать? Формы, какие будут в приложении? Или иерархию наследования форм?


S>Хочу еще добавить:

S>1. ИМХО, Ваш подход, когда один контролер для нескольких документов на практике не масштабируем. На Ваши 2 документа вы описали 10 функций, соответственно на 100-200 документов будет около 2000 функций. Рассмотрите Вашу идеологию MVC отдельно для каждого документа и затем объедините полученные модели минимальными связями.
Спасибо, подумаю над этим.


S>2. Ваши проверки:

SP>>1. Введенная дата счета не больше текущей даты;
SP>>2. Введенная дата накладной не больше даты счета и не больше текущей даты;
SP>>3. При сохранении документов табличная часть не должна быть пустой;
SP>>4. При редактировании накладной не можем изменять поле грузоотправитель.
S> на практике также не имеют особого смысла. Хозяйственные операции между продавцом и покупателем ведутся в договорной форме, сделка может быть сложной и проходить в длинный промежуток времени, счета и накладные могут многократно перевыставляться. Наше хаконодательство несовершенно, придумывать свои ограничения, даже если они кажутся логичными — это вставлять палки Бухгалтеру. Для начала рассмотрите только те ограничения, которые требуются законодательно, например в Положениях по бухгалтерскому учету (ПБУ), остальное бухгалтер проконтролирует сам, или даст замечания на доработку.
Спасибо за замечания, учту. Сейчас надо просто нарисовать как написано, а оптимизация будет потом.


И еще вопрос — нужно ли объектам документов быть синглтонами?
Re: Нужен совет по ООП и UML
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.09.10 10:14
Оценка:
Здравствуйте, SPeller, Вы писали:

SP>Вопрос: что еще нужно доделать в моей диаграмме? Подсказывали мне что нужно подробнее развернуть слой Представление, но куда и как — плохо понимаю. Подскажите пожалуйста.


Оооо... сферический ООП\MVC\UML\GOF в вакууме детектед.

1)Какой язык?
2)Какая технология построения UI?
3)Как отображаются эти самые документы на предметную область?
4)Как люди работают с соответствующими объектами предметной области?
5)Что требуется автоматизировать с помощью программы?
6)Какие функции требуются от той подсистемы, которую ты пытаешься изобразить?
7)Что используется для хранения данных?
8)Будет ли система многопользовательской (с конкурентным доступом) или нет?

Без ответов на все эти вопросы рисовать бессмысленно.

Я бы взял например 1с и нафигачил бы там, без всяких UML\ООП и паттернов.
Re[3]: Нужен совет по ООП и UML
От: Аноним  
Дата: 20.09.10 10:25
Оценка:
Здравствуйте, SPeller, Вы писали:

SP>... Формы, какие будут в приложении? Или иерархию наследования форм?

Если это формы, опишите формы, если они наследуемые покажите связь. Покажите связи между формами и контролером(ами), связи между формами и объектами модели

SP>И еще вопрос — нужно ли объектам документов быть синглтонами?

Лично я стараюсь по максимуму избежать глобальных переменных, особенно объектов, особенно относящихся к предметной области. Исключение только для статических системных данных типа путей к служебным файлам.

Singleton наверное модно. Но очень сложно создавать независимые алгоритмы доступа к глобальному объекту, если состояние этого объекта может в любой момент (паралельно) изменить другой алгоритм, написанный другим программистом.
Re: Нужен совет по ООП и UML
От: _Obelisk_ Россия http://www.ibm.com
Дата: 22.09.10 19:53
Оценка:
Здравствуйте, SPeller, Вы писали:

SP>Всем здравствуйте!


SP>Помогите решить задачу


Вы, часом, не с ВМиК МГУ, кафедра СП ?



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[2]: Нужен совет по ООП и UML
От: SPeller  
Дата: 22.09.10 22:19
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Вы, часом, не с ВМиК МГУ, кафедра СП ?


Нет, я гораздо дальше А что?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.