Практика. В природе практически не существует линейных процессов

В природе практически не существует линейных процессов. Все они:

· Направленные

· Периодические

Основополагающие периодические процессы:

1) Удар сердца - секунда

2) Сутки – время обращения земли вокруг Солнца (космическая проблема)

3) Месяц

4) Год

Приливы – отливы максимальны в полнолунье/новолунье. В это время воздействие на литосферу более сильное. Также повышается вероятность землетрясений (на 30%).

Солнце – не спокойно и не стабильно. Только в тепловом отношении оно имеет постоянные величины: 2 кал/см² в 1 мин – основной источник энергии на поверхности Земли.

Солнечная активность – периодичная деятельность, совпадающая с периодом обращения Юпитером Солнца – 10-12 лет (в среднем 11 лет).

Максимумы Солнечной активности в период с XIX по XXI вв.:

· 1895-1896

· 1905-1907

· 1917

· 1928

· 1937

· 1947

· 1957

· 1969-1970

· 1980

· 1990

· 2001

· 2011-2012

Также цикличность доказывает биогенетический закон Э.Геккель: индивидуальное развитие особи (онтогенез)является коротким и быстрым повторением важнейших этапов эволюции вида (филогенеза).

Как создавать хорошие правила: советы советчикам

Прежде чем перейти к специфическим правилам использования ОО-методов, необходимо спросить себя, что мы ожидаем от них. Методологи берут на себя большую ответственность: учить разработчиков, как следует писать их программы и как не следует этого делать. Трудно избежать сравнения с проповедниками, - позиция чреватая, как известно, злоупотреблениями, тем не менее, определим несколько правил над правилами: дадим советы советчикам.

Необходимость методологических руководств

Методология разработки ПО не является новой областью. Ее истоки восходят к известной работе Дейкстры "Go To Statement Considered Harmful" ( О вреде оператора Go To ) и последующим работам этого же автора и его коллег по структурному программированию. Но не все последующие методологические работы поддерживают достигнутый уровень стандартов.

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

Теория

Первая обязанность советчика - давать совет, согласующийся с предметной областью:

Пример Дейкстры может служить хорошей иллюстрацией. Он не пытался атаковать оператор Goto по причинам вкуса или чьих либо мнений - он приводил тщательно выверенную систему выводов. Кто-то мог не соглашаться с некоторыми из аргументов, но не мог отрицать, что заключение построено на хорошо продуманном взгляде на процесс разработки ПО. Не считаться с точкой зрения Дейкстры можно лишь при обнаружении изъяна в его теории и построении своей собственной теории для этого случая.

Практика

Теория - это дедуктивная часть методологии ПО. Но правила, основанные только на теории, могут быть опасными. Эмпирическая компонента столь же важна:

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

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

Опыта, анализа или даже анализа и проектирования явно недостаточно. Не один раз приходилось видеть, как консультанты по анализу выполняли свою работу, получали плату, и оставляли компанию с не более чем схемами с квадратиками и стрелками - документом анализа. А затем компания должна была извлекать нечто полезное из этих кусочков и делать свою трудную работу; иногда работа аналитиков оказывалась полностью бесполезной, поскольку не учитывала важных практических ограничений. Подход "только анализ" противоречит фундаментальным идеям бесшовности (seamlessness) и обратимости (reversibility), интегрированному жизненному циклу, характерному для объектной технологии, где анализ и проектирование свиваются с реализацией и сопровождением. Кто не прошел все этапы этого пути, вряд ли может давать методологические советы.