Компьютерный форум
Правила
Вернуться   Компьютерный форум > Форум программистов > Теория программирования > Общие вопросы создания ПО
Перезагрузить страницу Краеугольные столпы проектирования
Ответ
 
Опции темы Опции просмотра
  (#16 (permalink)) Старый
S.Yu.Gubanov S.Yu.Gubanov вне форума
Member
 
Сообщений: 587
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 03.12.2002
По умолчанию 03.12.2002, 18:13

Цитата:
Originally posted by Влад
[b]Я сейчас для небольших проектов применяю XP - eXtreme Programming. Это позволяет практически на любом этапе проекта иметь работающий код, и получается лучше взаимопонимание как в команде разработчиков, так и с заказчиком, если он видит проект в развитии. Да и мне легче оценить готовность продукта к выпуску и назвать заказчику реальные сроки готовности и реальные же возможности продукта.
Вот вот, купил я эту книгу недавно (Кент Бек "Экстремальное программирование"), уже до середины дочитал. Круто. Основная идея - стоимость внесения изменений в программу при ХР программировании растет не экспоненциально, а полого выходя на горизонтальную ассимптотику. Поэтому не надо боятся, что потом придется 100 раз переписывать код...
Ответить с цитированием
  (#17 (permalink)) Старый
AssAsin AssAsin вне форума
Member
 
Сообщений: 383
Сказал(а) спасибо: 0
Поблагодарили 1 раз в 1 сообщении
Регистрация: 02.11.2002
По умолчанию 26.01.2003, 18:45

Цитата:
Originally posted by Влад
[b]Я сейчас для небольших проектов применяю XP - eXtreme Programming...
Нарвался на сайт www.xprogramming.ru. Читаю в захлеб. Какой же я, однако, ламер! Щас сяду и для начала напишу систему unit-тестов.
Ответить с цитированием
  (#18 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию В ожидании дятла... - 02.08.2003, 16:37

Можно рассмотреть применение различных методик проектирования. Обычно выделяют две основные методики “waterfall” (в различных модификациях) и XP.
Методика “waterfall” подразумевает последовательное выполнение нескольких основных стадий разработки:
1.Построение аналитической модели;
2.Проектирование на основе аналитической модели;
3.Создание программного обеспечения в соответствии с проектной документацией;
4.Тестирование программного обеспечения;
5.Внедрение и сопровождение программного обеспечения.
Данная методика разработки хорошо зарекомендовала себя в небольших и средних проектах (~ до 1,000,000 строк). При увеличении размера и сложности проекта методика начала давать сбои. Наверное, лучше всего проблемы применения данной методики в крупных проектах описаны у Ф. Брукса. В чем состоят основные проблемы использования “waterfall” в крупных?
Во-первых, резко удлиняются сроки и качество выполнения каждой стадии. Например, для несложного программного обеспечения можно не строить аналитическую модель, но для сложной системы на ее построение может потребоваться несколько месяцев и даже лет. Но жизнь не стоит на месте и предметная область меняется. Поэтому первоначальная модель может устареть раньше, чем начнется проектирование и кодирование. В результате, происходит “бег по кругу”, модель создается и переделывается, а до конечного программного продукта дело так и не доходит.
Во-вторых, методике “waterfall” свойственна хроническая аритмия. Предположим, что команда аналитиков закончила свою работу по проекту, и в дело вступили проектировщики. Через некоторое время проектировщики наталкиваются на ошибку в модели и возвращают модель на доработку. Очевидно, что пока аналитики исправляют модель проектировщики сидят без дела. Но аналитики, когда закончили предыдущую модель, приступили к новой. Когда им возвращают эту предыдущую модель, то у них начинают “гореть” сроки, наступает т.н. “аврал”. Ошибки в срочном порядке правятся, но рабочий график нарушен. И точно также происходит на любых других стадиях: кто-то работает “в поте лица”, кто-то “бьет баклуши”. А так как от ошибок никто не застрахован, и ошибки имеют свойство проявляться в самый неподходящий момент, то работа над проектом происходит в крайне нервозной обстановке.
В-третьих, существуют значительные проблемы с администрированием проекта. Как было отмечено раньше, при “waterfall” очень сложно соблюдать сроки и выдерживать качество работ. Простой пример. Разработчик, действуя из самых благих побуждений вносит улучшения в какой-то кусок кода, но после этого перестают работать какие-то другие части программного обеспечения. Отсюда появляются требования к документированию каждого изменения, поддержке версий, регулярной сборке и тестированию. Все эти факторы резко снижают производительность работы команды.
Можно привести целый ряд и других негативных факторов применения методики “waterfall” в сложных проектах. Для преодоления недостатков методики было предпринято множество попыток ее улучшения, например, появились т.н. итерационные методики. Когда возврат на предыдущую стадию стал планироваться заранее, чтобы снизить общую аритмию работ. Однако, все эти улучшения давали некоторый локальный эффект, и при дальнейшем усложнении проектов терялись.
Методика XP основана на принципиально иной парадигме. Прежде всего бросается в глаза, то что в ней нет ни аналитической модели, ни даже описания проекта. Авторы методики говорят: “Не надо ничего проектировать, надо брать частную небольшую задачу и ее решать”. Когда решены несколько небольших задач, то они укрупняются. Одним из способов укрупнения является т.н. рефакторинг программного обеспечения. В ходе рефакторинга какие-то части программного обеспечения переписываются и перекомпоновываются дл того, чтобы в целом соответствовать новой более крупной задаче. Подразумевается, что за счет решения все новых частных задач и последующего рефакторинга можно в конце концов построить программную систему. Но также, как и в случае с “waterfall” разработчики сталкиваются с тем, что при создании простого программного обеспечения методика работает, а при возрастании сложности дает сбои. Основная проблема данной методики состоит в том, что объем постоянно переписываемого объема программного обеспечения растет быстрее, чем сложность проекта. Связано это с тем, что программное обеспечения не имеет архитектуры, которая задается в аналитической модели. Поэтому добавление новых задач приводит к тому, что в какой-то момент программное обеспечение просто “рушится”. Приходится переделывать значительную часть, но с добавлением новых задач, все повторяется вновь. Можно представить аналогию – строительства дома. Если нет проекта, но начато строительство. То фундамент будет одним, стены другими, крыша третьей (аналоги частных задач). При попытке собрать все это вместе, выясняется, что все части надо переделать, поскольку их просто невозможно состыковать. Хорошо, переделали. Но тут приносят окна, размером чуть больше стен. Начинаем перестраивать стены заново, но выясняется, что наш фундамент не рассчитан на такую нагрузку. И т.д. и так до бесконечности...

В качестве резюме. Один умный человек сказал, что “если бы строители строили так, как пишут программы, то первый же залетевший дятел разрушил бы цивилизацию”. С прискорбием... соглашаюсь с этим.
Ответить с цитированием
  (#19 (permalink)) Старый
Fireworm Fireworm вне форума
Member
 
Сообщений: 331
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.09.2002
По умолчанию 04.08.2003, 11:36

Кроме тобой перечисленных, есть еще итерационная модель, предложенная Бучем и Ко. Которая очень похожа на водопадную, но лишена очень многих ее недостатков.
Ответить с цитированием
  (#20 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию 04.08.2003, 12:45

Цитата:
Originally posted by Fireworm+-->
Цитата:
Кроме тобой перечисленных, есть еще итерационная модель, предложенная Бучем и Ко. Которая очень похожа на водопадную, но лишена очень многих ее недостатков.
Хм... А это про что?
<!--QuoteBegin-ASU

[b]Для преодоления недостатков методики было предпринято множество попыток ее улучшения, например, появились т.н. итерационные методики. Когда возврат на предыдущую стадию стал планироваться заранее, чтобы снизить общую аритмию работ. Однако, все эти улучшения давали некоторый локальный эффект, и при дальнейшем усложнении проектов терялись.
Ответить с цитированием
Ads.
  (#21 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию Извинения - 04.08.2003, 13:02

Предыдущее послание было от меня. Извините, что ушло без подписи.
Ответить с цитированием
  (#22 (permalink)) Старый
Timprog Timprog вне форума
Member
 
Сообщений: 23
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 26.07.2003
По умолчанию Делайте всё проще, проще, настолько, насколько это возможно, - 07.08.2003, 12:37

Проектирование проги - значит соглашаться с теми, кто говорит что ООП - это плохо и что goto - это хорошо. А потом соглашаться с теми, кто говорил, что это не так...

P.S.
но не более того.
Ответить с цитированием
  (#23 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию Re: Делайте всё проще, проще, настолько, насколько это возмо - 08.08.2003, 10:08

Цитата:
Originally posted by Timprog
[b]Проектирование проги - значит соглашаться с теми, кто говорит что ООП - это плохо и что goto - это хорошо. А потом соглашаться с теми, кто говорил, что это не так...
P.S. но не более того.
Проектирование - это доведение идеи (или аналитической модели) до состояния пригодного для реализации. Парадигмы языков программирования, как и их операторы, совсем другая история...
Ответить с цитированием
  (#24 (permalink)) Старый
Timprog Timprog вне форума
Member
 
Сообщений: 23
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 26.07.2003
По умолчанию Об высшем уровне абстракции - 09.08.2003, 08:08

Всё равно, парадигма программирования навязывает путь решения поставленной задачи. Иногда даже наличие/отсутствие нужных аппаратных ресурсов - это к вопросу переностмости - также навязывает реализацию под конкретную платформу (естесственно, здесь идёт речь об огромных проектах, а не о "hello мир" - где вопрос с переносимостью был решён полвека назад...). Например, сотоит ли метод Рунге-Кутта рассматривать как класс? Или его стоит рассмотреть как функцию (подпрограмму, процедуру). Что будет, если использовать goto? - вопросы проэктирования тесно связаны с языком реализации (может и языками). Всеми избитое словосочетание итеративный процесс - корень проектирования. Сразу встают вопросы повторного использования кода уже существующих общих библиотек, или писать спецпроект более конкретно подходящий для решения задачи - это почти всегда более эффективно. По поводу железа: например, использование MMX и SSE - сразу навязывает путь решения, например, использование float может привести к вопросу о сходимости решения и накоплению ошибок, double отчасти решает проблему - а может необходимо написать библиотеку для работы с числами с произвольным числом разрядов. Здесь имеется в виду не формализацию (проектирование) физической задачи, а проектирование программного обеспечения. Ведь формулы и методика их вывода, построение модели - это математика (грубо говоря), а числа, облегчение решения задачи на компе, - это программы (в том числе и формулы - так как символические вычисления по своей природе целочисленны). Вообщем, иногда постановка физической задачи может навязываться имеющимися ресурсами: можем ли мы промоделировать ядерный взрыв или рождение Вселенной на 8086, если в задачи фигурируют массивы более чем 100e6 байт? Естесственно, мы должны составить такие уравнения, чтобы их мог решить конкретный компьютер, и выбрать наиболее эффективную методику счёта. При этом естесственно, мы принимаем соответствующий уровень допущения.
Ответить с цитированием
Ads
  (#25 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию Re: Об высшем уровне абстракции - 09.08.2003, 11:12

Цитата:
Originally posted by Timprog+-->
Цитата:
Всё равно, парадигма программирования навязывает путь решения поставленной задачи.
Хм... Очень неосторожное заявление (IMHO).

<!--QuoteBegin-Timprog

[b]Иногда даже наличие/отсутствие нужных аппаратных ресурсов - это к вопросу переностмости - также навязывает реализацию под конкретную платформу (естесственно, здесь идёт речь об огромных проектах, а не о "hello мир" - где вопрос с переносимостью был решён полвека назад...).
Хорошо, давайте попробуем разобраться. Рассмотрим самый нижний уровень проектирования – алгоритм. Алгоритм, по своей сути, не зависит от того на каком языке его будут реализовывать, он определяет некоторую логику в виде совокупности элементарных действий. Безусловно, в каком-то языке программирования каждый “шаг” может соответствовать одному оператору или вызову подпрограммы. В другом языке программирования такого соответствия может не быть, и тогда необходимо выполнить проекцию алгоритма на операторы данного языка. Однако существо алгоритма не меняется от того, на каком языке его реализуют.
Поднимемся на один уровень выше, и рассмотрим проектирование программы. Программу можно рассматривать, как логически связную совокупность алгоритмов. При этом логика может быть “жесткой” (прошитой в коде в виде вызовов подпрограмм) или “мягкой” (определяемой пользователем программы, непосредственно при работе программы). Но снова проектирование логики (и/или металогики) программы никак не зависит от того, на каком языке ее будут реализовывать. И это справедливо для любой программы, будь то работа с мультимедийным файлом или прием заказа от клиента.
Можно подняться на еще более высокий уровень и посмотреть на проектирование системы. Логика данных (тип и связи) не зависит от того, какая СУБД применяется в данной системе, она [логика] определяется предметной областью. В свою очередь программы, реализующие интерфейс с пользователем, тоже имеют строго определенную функциональность, то есть, заданный набор операций. (О программах говорилось на предыдущем шаге). Поэтому и при создании сложных систем нет зависимости от языков программирования.
Можно сказать и более жестко, что раннее “привязывание” проекта к платформе или языку программирования является грубейшей ошибкой проектирования.

Цитата:
Originally posted by Timprog+-->
Цитата:
Например, сотоит ли метод Рунге-Кутта рассматривать как класс? Или его стоит рассмотреть как функцию (подпрограмму, процедуру).
Говорят, что хороший вопрос содержит в себе ответ. Ваш вопрос интересен тем, что он содержит... казус. Прочитайте его внимательно: “Стоит ли метод... рассматривать, как класс?”. Ответ вполне очевиден – метод, как класс, рассматривать нельзя, его можно рассматривать, как метод класса или как подпрограмму (функцию или процедуру).

Цитата:
Originally posted by Timprog+-->
Цитата:
Что будет, если использовать goto? - вопросы проэктирования тесно связаны с языком реализации (может и языками).
Если использовать GoTo грамотно, то будет польза, если безграмотно, то – ущерб. Существует несколько ситуаций, когда применение GoTo вполне оправдано (не происходит превращение программы в “спагетти”, наоборот, логика реализации становится более простой и эффективной).

Цитата:
Originally posted by Timprog
[b]Всеми избитое словосочетание итеративный процесс - корень проектирования.
Еще одно неосторожное заявление. Существует несколько методов проектирования и итерационный метод только один из них, не более того. В наших задачах этот метод очень неэффективен, и мы его не используем.

<!--QuoteBegin-Timprog
@
[b]Сразу встают вопросы повторного использования кода уже существующих общих библиотек, или писать спецпроект более конкретно подходящий для решения задачи - это почти всегда более эффективно. По поводу железа: например, использование MMX и SSE - сразу навязывает путь решения, например, использование float может привести к вопросу о сходимости решения и накоплению ошибок, double отчасти решает проблему - а может необходимо написать библиотеку для работы с числами с произвольным числом разрядов. Здесь имеется в виду не формализацию (проектирование) физической задачи, а проектирование программного обеспечения.
На самом деле, Вы рассматриваете уже не проектную часть, а реализационную, то есть, стадию кодирования. Именно здесь надо принимать решения о том, какими языками, библиотеками, компонентами и протоколами пользоваться, как эффективнее реализовать тот или иной алгоритм, как достичь требуемой точности и т.п.. Но к проектированию – это не имеет ни малейшего отношения. Мало того, если совместить стадию кодирования и проектирования, то это послужит источником серьезных проблем при развитии и сопровождении проекта.

<!--QuoteBegin-Timprog

[b]Ведь формулы и методика их вывода, построение модели - это математика (грубо говоря), а числа, облегчение решения задачи на компе, - это программы (в том числе и формулы - так как символические вычисления по своей природе целочисленны). Вообщем, иногда постановка физической задачи может навязываться имеющимися ресурсами: можем ли мы промоделировать ядерный взрыв или рождение Вселенной на 8086, если в задачи фигурируют массивы более чем 100e6 байт? Естесственно, мы должны составить такие уравнения, чтобы их мог решить конкретный компьютер, и выбрать наиболее эффективную методику счёта. При этом естесственно, мы принимаем соответствующий уровень допущения.
Ну, а здесь в рассмотрение введена еще и стадия моделирования, которая, по своей сути, предшествует стадии проектирования. Выбор/построение модели – это совершенно отдельная задача. Создание проекта на основании выбранной модели – это другая задача. Наконец, реализация проекта – это третья задача. Каждый уровень имеет свои средства, технологии и ограничения. Но из этого совсем не следует, что задачи разных уровней надо решать одновременно и называть это “проектированием”.
Ответить с цитированием
  (#26 (permalink)) Старый
Timprog Timprog вне форума
Member
 
Сообщений: 23
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 26.07.2003
По умолчанию About всяком - 10.08.2003, 11:30

Метод: метод РК - это Математический метод, а не програмнный в виде метода класса (функции-члена). Если слово "метод" слепо интерпретировать как алгоритм - то встаёт более фундаментальный вопрос: зачем использовать ООП - когда всё можно реализовывать функциями, то есть наследование, полиморфизм, ad-hoc полиморфизм - всё равно превращаются в вызовы функций над глобальными данными - в памяти нет объектов с точки зрения железа. объект как экземлпяр класса/структуры - это артефакт (искусственно созданная именная облать памяти - так обозначили). Любую ООП программу можно записать в виде функций и набора данных. ООП - это для человека, а не для машины (здесь можно сделать небольшое отступление по поводу таких вещей, как программы, которые пишут программы, а ещё чего похлеще - программы, оптимизирующие сами себя).

Высший уровень абстракции:
как решается проблема? Вручную? На компе: Перетаскиванием цветных рюшечек по монитору и кликаньями мышки? Написанием программ на уровне "если буковка а - замени её на б"? Или затёртой до контактов клавой с ипользованием "cmp, jmp,mov"?
По моему, первоначальная фаза любого проекта - выбор имеющихся средств для его реализации (так как я имею дело с не чисто программными проектами, а с физическими - поэтому программы - это часть реализации именно физического проекта, хотя принципы проектирования, скажем мощных выпрямителей и форточек - на высшем уровне абстракции одинаковы). Если проект программный - (кстати, алгоритм проекта, и программный алгоритм - это всё-таки разные вещи, и вообще слово алгоритм - само по себе абстрактно: оно математично, в природе алгоритмов нет - есть время и пространство - тема отдельного рассуждения, хотя, по последним мыслям, Вселенная зародилась не из большого взрыва, а существовала бесконечно долго, и представляет собой фрактал, который может быть описан с помощью целых чисел. Пример -1 0 1 - позитрон, фотон, электрон, координаты пространства/времени квантованы, поэтому положение частицы определённо, но с вероятностью. см. таже соотношение неопределённостей Гейзенберга, ОТО, уравнение Шрёдингера итд. - похоже, отвлеклися...), то как можно создавать то, об инструментах создания которого ничего не известно (грубо говоря)...

Алгоритм: стадия реализации.

Возможно, здесь есть небольшое непонимание, или скорее нет конкретного примера, чтобы можно было показать, что на относительно высоком уровне абстракции выбирается язык и парадигма, и что задумка так или иначе связана с конкретной реализацией. Нельзя полностью инкапсулировать парадигму и язык, спрятав его за интерфейсы - это может быть неэффективно в "большом"
Ответить с цитированием
  (#27 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию Re: About всяком - 10.08.2003, 13:27

Цитата:
Originally posted by Timprog+-->
Цитата:
Метод: метод РК - это Математический метод, а не програмнный в виде метода класса (функции-члена).
У меня нет ни малейших сомнений в том, что метод РК можно представить в виде программного метода, но есть большие сомнения в том что его можно или нужно представлять в виде класса. Само понятие метода в математике, программировании и обыденной жизни имеет много общего (не случайно же используется один термин), хотя, безусловно, существуют и различия. Но в любом случае под методом понимается целенаправленная совокупность действий (элементарных или составных).
<!--QuoteBegin-Timprog

[b]Если слово "метод" слепо интерпретировать как алгоритм - то встаёт более фундаментальный вопрос: зачем использовать ООП
Это риторический вопрос. Если нет понимания сути любого явления или сущности, то лучше ими не пользоваться (хотя бы ради безопасности).
Цитата:
Originally posted by Timprog+-->
Цитата:
- когда всё можно реализовывать функциями, то есть наследование, полиморфизм, ad-hoc полиморфизм - всё равно превращаются в вызовы функций над глобальными данными - в памяти нет объектов с точки зрения железа. объект как экземлпяр класса/структуры - это артефакт (искусственно созданная именная облать памяти - так обозначили). Любую ООП программу можно записать в виде функций и набора данных. ООП - это для человека, а не для машины
Могу заверить, что любой процессор на уровне микрокода работает только с битами, и сам по себе он не умеет ни складывать, ни вычитать, ни умножать, ни делить. Все эти и многие другие операции реализованы в виде микропрограмм. Безусловно, можно было бы до сих пор сложение описывать, как набор битовых операций. Можно, но надо ли? Будет ли это удобно разработчикам программного обеспечения и пользователям. Точно также можно обходится и без ООП. Можно, но надо ли?
<!--QuoteBegin-Timprog

[b]Высший уровень абстракции:
как решается проблема? Вручную? На компе: Перетаскиванием цветных рюшечек по монитору и кликаньями мышки? Написанием программ на уровне "если буковка а - замени её на б"? Или затёртой до контактов клавой с ипользованием "cmp, jmp,mov"?
Простите, но не очень понятно о какой проблеме Вы говорите, что Вы подразумеваете под “высшим уровнем абстракции”. Целью абстрагирования является концентрированная передача сути явления или объекта (в философском, а не программном смысле этого слова). Какое отношение к передачи сути имеют сентенции по поводу “рюшечек”, “мышки”, “буковок” и пр.?
Цитата:
Originally posted by Timprog+-->
Цитата:
По моему, первоначальная фаза любого проекта - выбор имеющихся средств для его реализации (так как я имею дело с не чисто программными проектами, а с физическими - поэтому программы - это часть реализации именно физического проекта, хотя принципы проектирования, скажем мощных выпрямителей и форточек - на высшем уровне абстракции одинаковы).
Другими словами, Вы принимаете решения о том, с помощью чего делать, до того, как Вам становится известно, что нужно сделать и с помощью каких технологий это “нечто” можно создать (да, и возможно ли создание этого “нечто” вообще)?
Цитата:
Originally posted by Timprog+-->
Цитата:
Если проект программный - (кстати, алгоритм проекта, и программный алгоритм - это всё-таки разные вещи, и вообще слово алгоритм - само по себе абстрактно: оно математично, в природе алгоритмов нет - есть время и пространство - тема отдельного рассуждения
Любое слово – есть абстракция. Даже такие простые слова, как стол или окно. Если под алгоритмом понимать заданную последовательность операций, то оно вполне подойдет и для проекта и для программы.
Цитата:
Originally posted by Timprog
[b]хотя, по последним мыслям, Вселенная зародилась не из большого взрыва
Фантазий на эту тему даже больше, чем людей, которые “изучают” процесс зарождения Вселенной.
<!--QuoteBegin-Timprog
@
[b]то как можно создавать то, об инструментах создания которого ничего не известно (грубо говоря)...
Узнав, что нужно создавать, мне будет значительно проще выбрать адекватный инструмент. А Вы видимо считаете, что существует некий универсальный инструмент, с помощью которого можно сделать все?
<!--QuoteBegin-Timprog

[b]Алгоритм: стадия реализации.
Возможно, здесь есть небольшое непонимание, или скорее нет конкретного примера, чтобы можно было показать, что на относительно высоком уровне абстракции выбирается язык и парадигма, и что задумка так или иначе связана с конкретной реализацией. Нельзя полностью инкапсулировать парадигму и язык, спрятав его за интерфейсы - это может быть неэффективно в "большом"
На мой взгляд, Вы как-то слишком широко трактуете слово “абстракция”... Любые инструменты выбираются на соответствующей стадии работы над проектом. Если аналитическая модель подразумевает использование в проекте СУБД, то происходит выбор СУБД, удовлетворяющей аналитической модели, CASE-средств разработки БД и пр. Точно также определяются и остальные инструменты, необходимые для разработки. При этом критерии выбора хорошо известны:
- трудоемкость решения задачи с помощью данного инструмента и последующего сопровождения и развития;
- эффективность, полученного с помощью данного инструмента, решения;
- стоимость инструментального средства;
- надежность фирмы-поставщика инструмента;
- возможность дальнейшего развития инструмента в нужном направлении.
Но для того, чтобы принять грамотное решение при выборе инструментальных средств, необходимо хорошо понимать, под какую задачу выбираются эти средства.
Ответить с цитированием
  (#28 (permalink)) Старый
Timprog Timprog вне форума
Member
 
Сообщений: 23
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 26.07.2003
По умолчанию 12.08.2003, 08:09

По поводу RK - численных методов решения дифуров уйма, в том числе и модификаций методов RK. Так как им надо скармливать по одинаковые виду одни и те же структуры данных (например, начальные условия, количество итераций итд) в виде класса его можно представить как отдельный метод Рунге-Кутта (конструктор: поле итераций, поле конца выполнения, поле задания точности, поля входного массива, выходного, каких-нть вспомогательных данных) а так как их много, и они почти одинаковы по структуре, поэтому желательно было бы, а может и надо бы создать из них иерархию, где базовыми классом являлось бы что-то вроде "численный метод" - существительное, которое может пополнить словарь предметной области.
Могу заверить, что процессор можно представить как совокупность RS-триггеров и элементов НЕ и И, а также буферных элементов (усилителей) и элементов питания. И нет там никаких микропрограмм...
Так же могу заверить, что нет там никаких триггеров и логических элементов. Там есть электрическая цепь, состоящая из транзисторов, диодов, конденсаторов, резисторов, проводников.
Могу заверить, что нет там никаких транзисторов, и прочего. Там есть кристалл полупроводника с разными по величине и типу областями легирования, с областями металлизации и диэлектрика.
А дальше, заверить пока ничего не могу...
Высший уровень абстракции: словарь предметной области (грубо говоря). И ничего более.
Алгоритмы = взаимодействие объектов, хотя спорный вопрос: можно ли поместить в словарь предметной области "открыватель файла" и вообще выражение вида "(сущ)глагол+сущ", иногда бывает, что действие удобно выразить с помощью класса.
Взаимодействие классов (наследование, ассоциация, агрегация, использование) - также представляет собой высший уровень (CRC процесс или другое).
Существует самый универсальный инструмент проектирования - это и есть абстрагирование - имеется в виду: можно рассчитать, а можно делать конкретные опыты. Расчёт = абстрагирование от конкретного.
Ответить с цитированием
  (#29 (permalink)) Старый
Fireworm Fireworm вне форума
Member
 
Сообщений: 331
Сказал(а) спасибо: 0
Поблагодарили 0 раз(а) в 0 сообщениях
Регистрация: 23.09.2002
По умолчанию 12.08.2003, 12:09

Цитата:
так как я имею дело с не чисто программными проектами, а с физическими - поэтому
Мне кажется, что люди работают с разными масштабами приложений, отсюда и их недопонимание друг-друга. Численные методы, это действительно не тот уровень задач, для которых необходимо применять какие-то технологии проектирования, и совсем можно обойтись без ООП.
Но если разрабатывается система, над которой работают хотябы 20 программистов, в течении 5 лет - то без этих технологий проект загнется уже через полгода, просто потому, что никто не сможет удерживать в голове весь код.
Ответить с цитированием
  (#30 (permalink)) Старый
Anonymous
Guest
 
Сообщений: n/a
По умолчанию Метод или класс? - 12.08.2003, 13:46

Цитата:
Originally posted by Timprog
[b]По поводу RK - численных методов решения дифуров уйма, в том числе и модификаций методов RK. Так как им надо скармливать по одинаковые виду одни и те же структуры данных (например, начальные условия, количество итераций итд) в виде класса его можно представить как отдельный метод Рунге-Кутта (конструктор: поле итераций, поле конца выполнения, поле задания точности, поля входного массива, выходного, каких-нть вспомогательных данных) а так как их много, и они почти одинаковы по структуре, поэтому желательно было бы, а может и надо бы создать из них иерархию, где базовыми классом являлось бы что-то вроде "численный метод" - существительное, которое может пополнить словарь предметной области.
Что ж, давайте попробуем рассуждать. Очевидно, что существует некоторое внешнее программное обеспечение (ПО), которому необходимо проводить вычисления по методу РК. Наверное, Вы не станете возражать против того, что требования к вычислениям формирует именно внешнее ПО, поскольку только оно знает, для чего проводятся вычисления. Если программно реализовано несколько вариантов метода, то внешнее ПО должно либо указать вариант метода, либо предъявить список требований достаточный для того, чтобы можно было сделать выбор метода. Следовательно, необходима максимум одна дополнительная функция, которая по заданным требованиям определяет нужный вариант метода.

Цитата:
Originally posted by Timprog+-->
Цитата:
Высший уровень абстракции: словарь предметной области (грубо говоря). И ничего более.
К сожалению, словаря может оказаться недостаточно... если под словарем, как обычно, понимается набор терминов и определений.

<!--QuoteBegin-Timprog

[b]Алгоритмы = взаимодействие объектов, хотя спорный вопрос: можно ли поместить в словарь предметной области "открыватель файла" и вообще выражение вида "(сущ)глагол+сущ", иногда бывает, что действие удобно выразить с помощью класса.
Алгоритмы – не есть взаимодействие объектов. Взаимодействие объектов может быть задано алгоритмически, но взаимодействие объектов может быть и достаточно хаотичным, управляемым по событиям, где события сами могут быть результатами взаимодействия объектов.

Цитата:
Originally posted by Timprog+-->
Цитата:
Взаимодействие классов (наследование, ассоциация, агрегация, использование) - также представляет собой высший уровень (CRC процесс или другое).
Думаю, что пора остановиться... Разгребать то, что остается в головах после знакомства с UML – весьма неблагодарное занятие.

<!--QuoteBegin-Timprog

[b]Существует самый универсальный инструмент проектирования - это и есть абстрагирование - имеется в виду: можно рассчитать, а можно делать конкретные опыты. Расчёт = абстрагирование от конкретного.
Вообще то, с точностью до наоборот. Проектирование – это доведение ранее полученной абстракной аналитической модели до вида пригодного для реализации. Абстрагированием занимаются системные аналитики, а не проектировщики.
Ответить с цитированием
Ответ

Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Trackbacks are Вкл.
Pingbacks are Вкл.
Refbacks are Выкл.


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Ведущий специалист отдела проектирования (Страховая Компания (ТОР-3)) Liubov Работа 0 29.08.2011 17:33
Паттерны проектирования anonymous Мысли вслух 5 17.07.2010 19:33
Ищу энтузиастов для проектирования элементов ИИ Irkin Некоммерческие проекты 0 20.09.2008 02:25
Инженер проектирования ЦОД (SUN, Solaris), Москва Business Craft Работа 0 04.07.2008 14:32
Подскажите программы для проектирования. SS Любые вопросы от новичков 3 14.06.2008 08:50
Разработчик правил проектирования топологии (Product Engineer) 2000-2500$ youth Работа 0 24.07.2007 13:04
Паттерны проектирования Kutushut Общие вопросы создания ПО 9 12.01.2007 10:31
Паттерны проектирования книги, ресурсы, библиотеки BreakPointMAN С/С++ 8 10.03.2006 17:56
Паттерн проектирования Абстрактный Агрегат S.Yu.Gubanov Общие вопросы создания ПО 1 16.08.2004 21:16
Как SmallTalk взаимодействует с технологиями объектно-ориентированного проектирования VVasia Smalltalk 5 22.06.2004 17:58



Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Нardforum.ru - компьютерный форум и программирование, форум программистов