---|Ветка была без названия|---

← →
euru (2003-09-29 09:04) [80]

← →
Некрофил-затейник__ (2003-09-29 10:41) [81]

Ну так он в книге "водопадом" все примеры строит то есть есть какой то этап все обдумывается следующий проектируется следующий пишется. Хотя он тоже иной раз прыгает между этапами но редко а вообще вся учебная литература оперирует "водопадом".

← →
Некрофил-затейник__ (2003-09-29 13:19) [82]

← →
euru (2003-09-29 16:30) [83]

Так водопада-то и не получается.

Если бы он в своей книге написал, что есть такие ОО-языки, типа С++, Object Pascal и т.д, а на них очень удобно реализовывать один из видов объектного анализа и проектирования, я бы с ним согласился. Это была бы книга прикладного назначения, типа "Как использовать С++ для ООА и ООД."

Или если бы он доказал без привлечения языка пр, что ООА и ООП - это лучший метод анализа и проектирования, поэтому были созданы такие языки как С++ и т.д., на которых эти методы удобно претворять в жизнь, я бы тоже согласился. Это был бы какой-нибудь теоретический труд, типа "Теоретическое обоснование ООА и ООД как единственно возможных оптимальных методов анализа и проектирования".

А у него какой-то замкнутый круг получается: доказываем, что нужно использовать ОО-проектирование, потому что результат проектирования удобно осуществлять на ОО-языках, а, с другой стороны, нужно использовать ОО-языки, потому что, как мы доказали выше, нужно использовать ОО-проектирование.
Это все равно что утверждать (возможно, пример не очень удачен), что нужно на автомобилях ездить задом, потому что там есть передача заднего хода, а, с другой стороны, при езде нужно использовать передачу заднего хода, потому что, как мы уже доказали выше, нужно ездить задом.

← →
vuk (2003-09-29 17:07) [84]

to euru:
>А у него какой-то замкнутый круг получается
Блин, да плюньте Вы на это и смотрите глубже, в суть методики. Язык там ни при чем.

← →
euru (2003-09-29 20:13) [85]

vuk © (29.09.03 17:07) [84]
>Блин, да плюньте Вы на это и смотрите глубже, в суть методики. Язык там ни при чем.

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

Т.е. выбор языка влияет на процесс анализа и проектирования и, соответственно, искажает модель.

← →
vuk (2003-09-29 20:28) [86]

to euru:
>решения проектов выглядели бы по-другому
Решения - да, но не принципы анализа.

← →
euru (2003-09-29 20:49) [87]

>vuk © (29.09.03 20:28) [86]
А я на принципы и не посягался. Они, я думаю, везде одинаковы: исследовать реальное явление, выявить закономерности, связи, построить модель.
Теперь берем проектировщика. Он знает, что в дальнейшем программирование того, что он наваяет, будет идти на каком-то структурированном языке. Он знает, что там важны структуры данных, алгоритмы их обработки обработки, и спроектирует соответствующую этой идеологии модель.
Если бы применялся какой-нибудь ОО-язык, проектирвщик учел бы особенности языка этого типа (выявление классов, объединение одинаковых свойств и поведения в один класс, специализация с помощью наследования) и спроектировал бы модель в соответствии с этой идеологией.

← →
Vuk (2003-09-29 21:05) [88]

Все зависит от того, модель чего рассматривается. Если модель программных компонентов, то, естественно, язык должен учитываться. Если же рассматривается модель предметной области, то в этом случае не стоит принимать такие решения, которые потом могут сказаться на возможности реализации на конкретном языке программирования. Ведь если посмотреть внимательно, то, по большому счету, возможности конкретного языка нужно учитывать при проектировании иерархии и реализации классов, но ведь это уже проектирование, а не анализ (OOD, а не OOA)...

← →
euru (2003-09-29 21:18) [89]

>Vuk © (29.09.03 21:05) [88]
А откуда взялась эта иерархия классов, которую нужно проектировать? Сдается мне, при анализе. А почему иерархия классов, а не что-либо другое?

← →
vuk (2003-09-29 21:28) [90]

>А откуда взялась эта иерархия классов, которую нужно
>проектировать?
Там до иерархии классов еще много чего интересного есть... Use Cases, например (на русский обычно термин переводится как "инциденты").

>А почему иерархия классов, а не что-либо другое?
Да вовсе не обязательно. Это могут получиться интерфейсы, а не классы...

← →
vuk (2003-09-29 21:36) [91]

Тьфу, блин, Use Case - не инцидент, а прецедент.

← →
Некрофил-затейник__ (2003-09-30 07:47) [92]

euru
так в книге по мойму была оговорка что он использует С++ только по тому что его знает много народу на самом деле нечто подобное можно реализовать на любом ООП(я не стал искать его фразу только смысл как помню).

C++

class a{
protected:
int x;
};

cass b(){
public:
GetX(){return x;}
};

Delphi 5 ))))

type
a = class
protected
a:integer;
end;

b = class(a)
public
function GetX: integer;
end;

implementation

function b.GetX:integer;
begin
Result := x;
end;

разници особой нет на языке зацикливатся не стоит.

← →
euru (2003-09-30 10:39) [93]

>vuk © (29.09.03 21:28) [90]
Использование прецедентов, стереотипов, диаграмм состояний и т.д. - вещь полезная и нужная. Только это, по-моему, в большей части относится к методологии анализа и проектирования, облегчающей формализацию описания модели, и одинаково применимо как к ООА, так и другим методам анализа.
Другое дело метод проектирования. Он влияет на то, как проектировщик отобразит реальную систему в своей модели. См. также euru © (29.09.03 20:49) [87]. Это касается и модели программных компонентов. За примером далеко ходить не нужно - возьмем интерфейс пользователя. Он состоит из стандартного набора компонентов: окна, поля ввода, меню, комбобоксы и т.д. Его модель при структурированном подходе представлена в Win32, а при ОО-подходе - в VCL.

>Некрофил-затейник__ © (30.09.03 07:47) [92]
ОО-языки действительно очень похожи друг на друга и базовые вещи достаточно легко однозначно отображаются между ними. Но даже и в этих языках есть некоторые понятия, которые не так-то легко отобразить из одного ОО-языка в другой (например, перегрузка операторов, множественное наследование из С++ в Delphi или множества, делегирование интерфейсов из Delphi в С++, а еще есть Java с поддержкой многопоточности, C# с атрибутами). А ведь ОО-языки - не единственно возможный вариант объектного программирования. В этом классе есть такие виды программирования, как аспектно-ориентированное, субъектно-ориентированное, аддитивное программирование (я эти названия встретил, пока знакомился с аспектно-ориентированным, возможно, существуют и еще какие-то варианты). Помимо объектного подхода еще есть автоматный, функциональный и т.д.

Я не хочу как-то умалить или очернить труд Буча (да у меня это и не получится :)). Его работы (и работы его единомышленников и последователей) сделали в свое время очередной шаг, позволяющий более реально отображать в модели реальную систему. Но неужели верен только предложенный им подход в построении модели? А если его подход наиболее верный, то неужели предложенный им вариант максимально лучший?

← →
Некрофил-затейник__ (2003-09-30 12:29) [94]

euru

IMHO
Скорее всего ООП это не единственно правильный метод проектирования ведь писались программы и до ООП. Проектирование как и сами языки не стоят на месте отрицать опыт того что было до ООП конечно нельзя но информации по ним сейчас найти очень сложно(если есть ссылки на информацию по этим методам дай ссылки пожалуйста). Просто ООП инструмент которым модно пользоватся сейчас.

IMHO*IMHO
Не всегда новое значит лучшее.

← →
Vuk (2003-09-30 12:46) [95]

to euru:
>Другое дело метод проектирования. Он влияет на то, как
>проектировщик отобразит реальную систему в своей модели.
И мало того, проектирование должно уже выполняться, в отличие от анализа, с учетом языка реализации.

>Помимо объектного подхода еще есть автоматный, функциональный и
>т.д.
Хм... Если пользоваться другими языками, то и подход к проектированию будет другим. Я нигде не вижу здесь противоречия.

← →
euru (2003-09-30 14:40) [96]

>Некрофил-затейник__ © (30.09.03 12:29) [94]
Пока искал информацию про АОП, наткнулся на такой сайт:
http://www.cs.ubc.ca/labs/spl/index.html
По-моему, достаточно интересный

>Не всегда новое значит лучшее.
Я бы сказал, не всегда усиленно рекламируемое новое значит лучшее.

>Vuk © (30.09.03 12:46) [95]
По-моему, анализ, проектирование и программирование должны рассматриваться раздельно. Это, словами Буча, слабосвязанные объекты. Отношения между ними должны описываться понятием "использование".
При анализе требуется просто исследование реальной модели: выявление сущностей, взаимодействий между ними и с внешним миром, каких-то закономерностей и т.д. Это еще называется декомпозицией.
При проектировании используются полученные результаты предыдущего шага для построения модели реальной системы (это уже синтез). При этом используется какой-то определенный метод проектирования. В идеале, конечно, должен использоваться тот метод, который наиболее точно отобразит реальную систему в модель.
При программировании (реализации) полученной модели используются опять-таки результаты предыдущего шага (проектирования). Опять-таки в идеале желательно использовать язык программирования, с помощью которого можно наиболее точно и естественно реализовать полученную модель (вряд ли С++ является естественным языком для реализации ИИ, а Пролог - для задач линейного программирования).

Обычно же поступают наоборот. Сначала выбирают, на каком языке будет реализовываться система (ограниченность собственных ресурсов, требование заказчика), и делают анализ и проектирование с учетом выбранного зарание языка.

← →
Vuk (2003-09-30 14:59) [97]

Я ж говорю - на анализ выбор языка не влияет никак. А вот на проектирование...

← →
euru (2003-09-30 15:24) [98]

>Vuk © (30.09.03 14:59) [97]
Почему? Если заранее выбрать язык программирования, то это и на анализ повлияет: мы невольно (или явно) будем использовать это знание при анализе. А это, в общем случае, исказит наш анализ (тут можно вспомнить, по-моему, Гейзенберга: использование инструмента в опытах влияет на результаты опыта).

Пример. Есть система, состоящаяя из множества разнородных объектов. Эти объекты совершают какие-то действия. Нужно вести для этих действий логи. Как это реализовать?

← →
vuk (2003-09-30 15:54) [99]

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

← →
euru (2003-09-30 16:09) [100]

ОК. Допустим, при анализе выявили все, что нам нужно. Как в общих чертах будет выглядеть эта модель? (Код необязательно :), мы же пока проектируем.)

← →
vuk (2003-09-30 16:31) [101]

Например так: имеется сущность "Операция", которая при переходе в состояние "Завершено" (или вообще при всех переходах состояний) осуществляет запись в лог.

← →
euru (2003-09-30 19:02) [102]

В ходе анализа выяснили, что у нас M независимых сущностей. В каждой такой сущности есть Ni(i = 1..M) операций, требующих записи в лог, для каждой сущности (количество операций может быть различно).
По отношению к этим М сущностям чем является сущность "Операция"? Каким образом она будет знать, что у одной из сущностей совершилась операция?
А еще возможны такие варианты:
- запись в лог перед совершением операции;
- в зависимости от состояния системы запис в лог подразумевает запись в файл, вывод на экран, отправка уведомления;

← →
vuk (2003-09-30 19:15) [103]

to euru:
>По отношению к этим М сущностям чем является сущность
>"Операция"?
Эти сущности могут являются, например, атрибутами операции.

>Каким образом она будет знать, что у одной из сущностей
>совершилась операция?
Операция совершается над чем-то и сам же объект "операция" занимается записью в лог. То есть операция уже обладает знаниями о своем завершении.

>- запись в лог перед совершением операции;
См. выше: (или вообще при всех переходах состояний)

>- в зависимости от состояния системы запис в лог подразумевает
>запись в файл, вывод на экран, отправка уведомления;
Это детали реализации. На этапе анализа это пофиг, я уже про это говорил. Достаточно знать, что есть возможность записи в лог.

← →
euru (2003-09-30 19:37) [104]

>Эти сущности могут являются, например, атрибутами операции.
Варианты:
- сущность Операция содержит в себе все экземпляры сущностей М (у каждой сущности может быть несколько экземпляров);
- сущность операция является предком сущностей, требующих регистрации;
- каждая сущность содержит в себе сущность Операция;
- какой-то другой вариант?

>Операция совершается над чем-то и сам же объект "операция" занимается записью в лог. То есть операция уже обладает знаниями о своем завершении.
Т.е. каждая операция, требующая регистрации, знает о существовании сущности Операция и с помощью нее сама делает регистрацию? Или я не так понял?

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

← →
vuk (2003-09-30 20:03) [105]

>Или я не так понял?
Есть сущность "Операция", у нее есть атрибуты - ссылки на другие сущности, над которыми операция производится. Так понятнее?

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

← →
euru (2003-09-30 21:03) [106]

Уточняем систему.

Есть некоторые сущности М1, М2, ... Mn. Каждая сущность может быть представлена несколькими экземплярами. Каждая сущность обладает своим набором операций, некоторые из этих операций одинаковы в разных сущностях. Необходимо, чтобы некоторые из этих операций регистрировались. Причем возможен вариант, что для одних экзмпляров одной и той же сущности регистрация необходима, а для других не нужна. Регистрация может осуществляться на различные носители информации. Какой именно выбрать носитель информации зависит от состояния системы в момент записи.

Проектируем модель.
Описываем сущности М1, М2 и т.д. Общих родителей будем искать?
Вводим сущность для регистрации операций, назовем ее Р. Атрибутами этой сущности будут ссылки на коллекции экземпляров для каждой сущности М1, М2, ... Еще одним атрибутом будет коллекция сущностей, реализующих какой-то определенный вид регистрации информации.
Когда какой-то экземпляр сущности выполняет какую-то операцию, он проверяет:
1. нужно ли ему ее регистрировать
2. если нужно, то запросить у системы, как именно регистрировать в данный момент (выбрать вид регистратора)
3. послать регистратору информацию для регистрации перед выполнением
4. выполнить операцию
5. послать регистратору информацию для регистрации после выполнения

← →
vuk (2003-09-30 22:04) [107]

А если так?

Есть Есть некоторые сущности М1, М2, ... Mn. Операция - это, в свою очередь, некая сущность, которая предназначена для манипуляции экземплярами M. То есть эти экземпляры выступают как атрибуты операции. Что и когда нужно регистрировать - решает сама операция на основании состояния своих атрибутов. Для регистрации чего-либо операция обращается к регистратору. Что делает регистратор дальше, нас на данном этапе не интересует - ему сказано регистрировать - он регистрирует, а уж как и где - дело регистратора.

← →
euru (2003-10-01 12:28) [108]

Система остается без изменений.

Уточняем модель.
Вводим сущность Единичная операция. Ее назначение: регистрация одной определенной операции одной из М-сущностей. Атрибутами этой сущности будет список всех М-сущностей, имеющих такую операцию. В свою очередь, элементом этого списка будет список экземпляров данной М-сущности, для которых нужно регистрировать эту операцию.

Система знает список всех Единичных операций О1, О2, ..., Ор.

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

Примечания.
1. Куда и как регистрировать Р-сущность определяет на основании состояния всей системы и переданных ему экземпляров М- и О-сущностей.
2. В общем случае сигнатура данной операции для каждой М-сущности может быть различной, поэтому О-сущность должна знать все сигнатуры М-сущностей.

← →
Vuk (2003-10-01 14:26) [109]

А зачем так сложно? Может все же проще?
Если у нас M являются активными объектами, то есть сами выполняют операции, то никакие лишние сущности не нужны и экземпляры M самостоятельно регистрируют все, что нужно. Если же M являются пассивными объектами и действия выполняются над экземплярами, то я уже все описал.

Можно только дополнительно уточнить для второго случая.

Операция О знает, какие экземпляры M нужны ей для корректной работы, и может проверить корректность своих атрибутов и знает сигнатуры только тех M, которые ей необходимы для работы. На остальные ей начхать. Операция знает последовательность действий, которые нужно провести над M для своего выполнения. Также операция знает, когда и как нужно выполнять регистрацию состояния, которой занимается Р.

← →
euru (2003-10-01 15:40) [110]

>А зачем так сложно?
Я пытаюсь спроектировать систему, используя методы ОО-проектирования, т.е. выявить классы (это сущности), определить их атрибуты и поведение (выполнение каких-то операций), а также возможные взаимодействия между ними. Возможно, я пошел не по тому пути, тогда жду ваш вариант.

>Если у нас M являются активными объектами,
Экземпляры М-сущностей являются активными объектами, потому что они выполняют операции, изменяя при этом состояние системы (свое состояние и/или состояние других объектов).

>Операция О знает
Что такое операция О? Это сущность? Если да, то какие у нее атрибуты и поведение, как именно она взаимодействует с М-сущностью?

И надо еще учесть, что мы проектируем систему, которая будет работать длительное время, в течение которого могут произойти изменения как с М-сущностями, так и с О-сущностями.

← →
Vuk (2003-10-01 15:56) [111]

>Что такое операция О? Это сущность?
Если рассматривать вариант 2, то да. В этом случае атрибутами будут являться экземпляры M (один или несколько) и какие-то дополнительные атрибуты, необходимые для выполнения операции. Для каждого конкретного действия может быть свой класс операции. Взаимодействие же с М будет зависеть от того, чем конкретно О занимается.

Если же операции выполняются не над объектом, а самим объектом, то все эти построения совершенно не нужны.

← →
Некрофил-затейник__ (2003-10-02 08:54) [112]

← →
euru (2003-10-02 11:13) [113]

>Некрофил-затейник__ © (02.10.03 08:54) [112]
Еще раз спасибо за помощь :)
Ваша модель очень проста и лаконична :))))

>Vuk © (01.10.03 15:56) [111]
Сорри. На работе новое задание появилось, так что я некоторое время буду занят. Но ближе к вечеру (в крайнем случае, завтра) я продолжу обсуждение.

← →
Некрофил-затейник__ (2003-10-02 13:54) [114]

>euru
мне просто тема интересна.

← →
euru (2003-10-03 14:36) [115]

>Vuk © (01.10.03 15:56) [111]
Да у нас, оказывается, аудитория есть :)

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

Предлагаю такой вариант.
Есть три М-сущности М1, М2, M3. Каждая сущность может быть представлена несколькими экземплярами (от 1 до n). Каждая сущность обладает набором операций, описывающих ее поведение.Некоторые из этих операций должны регистрировать свои действия. Допустим, у М1 - это операции О1 и О2; у М2 - операции О1 и О3; у М3 - операции О2 и О3.
Для каждой регистрируемой операции есть О-сущности. Их назначение - для заданной операции заданной М-сущности и дополнительных параметров зарегистрировать операцию на носителе информации.
Носители информации определяются Н-сущностями. Их назначение - зафиксировать входящую информацию от О-сущности.

Будут какие-нибудь уточнения?

← →
Vuk (2003-10-03 15:06) [116]

Да здесь, на мой взгляд, все элементарно.

1. Если операции выполняются самими экземплярами M, то никакие О-сущености не нужны вообще, это лишняя деталь здесь. Экземпляры М при выполнении операций сами зарегистрируют все, что им нужно.
О-сущности нужны только тогда, когда операция не является принадлежностью M. В этом случае Операция является самостоятельной сущностью, внешней для экземпляров М, над которыми эта операция производится. Я уже об этом писал несколько раз.

2. На уровне, где рассматриваются M1..Mn про носители можно забыть, т.к. важен сам факт регистрации, а не конкретный носитель. Достаточно иметь Регистратор. А вот при анализе на уровне Регистратора можно вспомнить и о носителях.

← →
euru (2003-10-03 16:33) [117]

Операции являются непосредственной частью М-сущности, потому что:
1. их выполнение может зависить от внутреннего состояния М-сущности, неизвестного Регистратору;
2. они существуют независимо от того, нужно или нет их регистрировать.
Таким образом, отделение операции от самой М-сущности будет не соответствовать реальной системе и усложнит ее модель.

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

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

Я пока не вижу, как это можно решить с помощью ООД.

← →
vuk (2003-10-03 16:48) [118]

>Таким образом, внесение процесса регистрации (возбуждения
>события о регистрации) в операцию М-сущности также не
>соответствует реальной системе и также усложнит модель.
IMHO как раз наоборот, это резко упрощает дело, т.к. всегда четко понятно, на ком лежит ответственность за инициацию регистрации (в данном случае - на экземпляре М).

← →
euru (2003-10-03 17:33) [119]

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

Как будет выглядеть модель? Так как в общем случае регистрируемые операции будут различны даже для разных экземпляров одной М-сущности, то возможны 2 варианта:
1. действия, связанные с регистрацией, будут выполняться на уровне М-сущностей (классов в ООД);
2. действия, связанные с регистрацией, будут выполняться на уровне экземпляров М-сущностей (объектов в ООД).

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

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

Где же здесь упрощение?

А ведь еще и система может со временем развиваться, причем по нескольким направлениям.
1. Через некоторое могут появиться новые регистрируемые операции, а в некоторых старых, наоборот, регистрация отмениться.
2. Может появиться еще какой-нибудь процесс, подобный регистрации. С другой стороны, регистрация может быть вообще отменена.

← →
euru (2003-10-03 18:49) [120]

>vuk ©
Рабочая неделя закончилась. А в выходные у меня не будет возможности выйти в Интернет. Если есть желание, можно будет продолжить на следующей неделе.

>Некрофил-затейник__ ©
Может за выходные еще несколько решений предложите? :)
Это эмоции. Просто было неожиданно узнать, что кто-то еще наблюдает за нашей дискуссией с Вуком.

---|Ветка была без названия|--- Найти похожие ветки