Кто разбирается в ОО проектировании? Совет бы мне...

← →
SPeller © (2010-09-16 12:29) [0]

Всем доброго времени суток!

Хочу уйти от простого кодирования и заняться проектированием. Начал касаться этой темы и понял что это моё. Читаю отрывочные материалы по проектированию и ОО проектированию и чувствую что мне понятны принципы как это всё делается, зачем и для чего. Некоторые моменты нахожу для себя актуальными, вспоминаю что сталкивался с этими проблемами, искал решения, но для вывода итогов "по фэншую" не хватало теоретических познаний. Мне это очень интересно. А когда мне интересно - я изучаю это достаточно быстро, главное начать. На нынешней работе заниматься этим бесполезно, ибо процесс разработки поставлен архаично и улучшать никому не надо. Точнее, надо, но есть препятствия личностного характера. Не суть. Суть в том, что нашел хорошую вакансию, всё подходит. Основной род занятий - проектирование с использованием UML, ООП и паттернов. С ОО программированием я дружу очень хорошо, умею в голове строить абстракции, выделять общее, разделять функционалы и т.п., в общем, с объектами обращаться умею и умею использовать преимущества ООП. Я эти объекты понимаю. И нужно выполнить тестовое задание. Главное - нарисовать диаграмму классов с использованием UML и паттернов. Поскольку ни опыта, ни теории, ни практики в этом направлении у меня не было, то дошел до некого предела понимания из того, что успел на скорую руку изучить. Мне нужен пинок под зад чтобы сообразить дальше. Спрашивать и советоваться в живую у меня не с кем, поэтому прошу помощи здесь.

Вот текст задания:

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

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

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

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

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

Вот схема: http://personal.primorye.ru/speller/Drawing1.gif . Сразу скажу что может быть это всё элементарно, может быть я нарисовал полную фигню. Я не прошу нарисовать за меня диаграмму или разжевать всё до мелочей. Мне нужны направления куда думать, где я не прав, полезные ссылки где можно быстро (или сравнительно быстро) найти решение. Практически такой же вариант схемы я уже отправлял и получил такой ответ:

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

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

← →
Kerk © (2010-09-16 12:45) [1]

У тебя на схеме есть Model, есть Controller, но не видно View.

← →
SPeller © (2010-09-16 12:47) [2]

Я так понял что view - это интерфейс пользователя. Его нужно подробнее расписать? Или это не пользовательский интерфейс?

← →
Дмитрий Тимохов (2010-09-16 12:50) [3]

спроси на RSDN в форумы / общие вопросы программирования / архитектура прогр. обеспечения.

там тебе точно хорош ответят. я в свое время много там чего узнал.

только первую часть вопроса убери.
там извиниться за вопрос не надо.

← →
Kerk © (2010-09-16 12:57) [4]

> SPeller © (16.09.10 12:47) [2]
>
> Я так понял что view - это интерфейс пользователя. Его нужно
> подробнее расписать? Или это не пользовательский интерфейс?

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

> Дмитрий Тимохов (16.09.10 12:50) [3]
>
> спроси на RSDN в форумы / общие вопросы программирования
> / архитектура прогр. обеспечения.

Хорошая мысль.

← →
Anatoly Podgoretsky © (2010-09-16 12:58) [5]

> SPeller (16.09.2010 12:29:00) [0]

Это жестоко и вероятно неоправдано.

1. Введенная дата счета не больше текущей даты;
2. Введенная дата накладной не больше даты счета и не больше текущей даты;

Лишаем возможности подготовки будущих документов.

-------------------------------------------

А это приводит к дублированию данных и возможно их несогласованности

• сумма счета;
• сумма по накладной;

Это должно быть расчетной величиной.

Дмитрий Тимохов (16.09.10 12:50) [3]
> спроси на RSDN в форумы / общие вопросы программирования
> / архитектура прогр. обеспечения.
Ок, учту ) Я чувствую что мне не хватает чего-то простого, поэтому не стал лезть на специализированные форумы, а решил тут поинтересоваться. Меня этот сайт программировать научил, поэтому за первым советом сюда же и пришел )

> только первую часть вопроса убери.
> там извиниться за вопрос не надо.
Это я спецом написал. Чтобы было предельно понятно что к чему. А то тут опасно задавать короткие вопросы :)

> Kerk © (16.09.10 12:57) [4]
> Это классы, реализующие пользовательский интерфейс. Оно
> же все не из воздуха берется. Насколько я понял, необходимо
> дать три четких слоя.
А какими классами описать интерфейс? Формочками-кнопочками? До какой глубины нужно детализировать? Наследование форм?

> Anatoly Podgoretsky © (16.09.10 12:58) [5]
> Лишаем возможности подготовки будущих документов.
> Это должно быть расчетной величиной.
Согласен что суммы должны в динамике считаться :) Об этом тоже в первую очередь подумал. С датами - просто не приходилось с такими документами сталкиваться. Наверное это нужно. Хотя задача скорее всего для простой проверки способности описывать, а вопросы оптимизации могут быть припасены на засыпку.

> SPeller (16.09.2010 13:13:06) [6]

Ну так и сделай в проекте данный комментарий.

Кто разбирается в ОО проектировании? Совет бы мне... Найти похожие ветки