|
| |
 |
Электронные компоненты Мануалы ЯХ К НИМ, причем любое изменение требований может нарушить их работоспособность. Однако в реальной жизни наивно ожидать четкого определения и согласования всех требований заказчика к сложной системе до тех пор, пока заказчик не увидит хотя бы частичное их воплошение. Причина этого кроется в неизбежном несовершенстве реально существующих организаций; люди бывают заняты, забывают некоторые подробности или вообще не интересуются ими; те, кому известны требования, не всегда участвуют в их определении, информация в процессе общения теряется. Различного рода оплошности, ошибки и упущения неизбежны, даже если приложить максимум усилий для их предотвращения. Вместе с тем программный комплекс на языке Ада, предназначенный для реализации некоторого требования, из-за упущенной детали может стать неприемлемым. Если же структура модуля, определенная в терминах типов данных, пакетов, задач, их интерфейсов и взаимодействий, становится неадекватной, то приходится модифицировать все модули или же поставлять систему, не отвечающую техническим требованиям. Очень желательно на ранних стадиях жизненного цикла системы возможно дольше воздерживаться от принятия таких проектных решений, которые в дальнейшем могли бы привести к необходимости крупных переделок в проекте. В идеале любые такие решения хорошо было бы отложить навсегда, предоставив заказчику возможность самому определять свои требования непосредственно в режиме удобного диалога с системой, ориентированной на удовлетворение потребностей пользователя.В некоторых прикладных сферах, например при поиске информации в базах данных, подобный подход постепенно становится все более и более реальным. В таких областях прикладные программы на языках высокого уровня не должны писаться прикладными программистами и затем транслироваться. Они конструируются высокоорганизованными программными средствами, входящими в состав интерфейса пользователя. Далее эти программы транслируются и выполняются в режиме интерпретации и в конечном итоге при необходимости модифицируются в процессе дальнейшего диалога пользователя с системой. В данном случае развитая возможность определения типов не требуется, поскольку природа объектов программирования может изменяться по мере эволюции самой системы. Такой подход можно определить как формулирование требований номере получения результатов, поскольку пользователь непосредственно видит результаты, к которым приводят его {требования, и имеет возможность уточнять их в интерактивном 24 Гмва 1 режиме для достижения необходимых целей. Этот подход называют также интерактивным макетированием. Метод, при котором требования формулируются по мере получения результатов, резко контрастирует с более традиционным подходом к разработке систем на основе концепции жизненного цикла, когда технические требования детально формулируются задолго до того, как удается увидеть результаты. Однако описываемый в данном разделе метод в принципе неприменим к задачам, которые не относятся к сфере автоматизации прикладного программирования. Такие задачи должны решаться в основном с ориентацией на концепцию жизненного цикла. Таким образом, использование языка Ада для описания и проектирования систем не накладывает никаких дополнительных ограничений на гибкость проектных решений по сравнению с органически присущими любому реальному проекту, выполненному на основе концепции жизненного цикла. Однако, каким бы ни был язык проектирования и реализации системы, изменения, вносимые в интерфейсы подсистем на последующих этапах проектирования, могут оказывать влияние на все подсистемы. При этом программирование или конструирование подсистем заново будет определять лишь часть общих затрат, вызванных подобным изменением в большом проекте. 1.3.4. Кустарное и промышленное производство программного обеспечения Вездесущие персональные ЭВМ делают процесс разработки программного обеспечения доступным практически каладому. Повсеместно начинает развиваться кустарное производство программных средств: пользователи, не являющиеся специалистами в области вычислительной техники, создают на своих персональных ЭВМ (зачастую весьма успешно) прикладное программное обеспечение для собственных нужд или даже на продажу. Такие люди обычно не склонны считать проектирование программ чем-то серьезным. Подобным образом ведут себя студенты, успешно освоившие несколько вводных курсов по программированию и уверенные, что они теперь с успехом смогут выполнять любую программистскую работу. Такое отношение довольно естественно, поскольку программирование может даТь само по себе впечатляющие результаты при сравнительно небольших затратах умственного труда на технологию программирования как таковую; достаточно изучить лишь несколько синтаксических правил языка и системных команд. В конце концов, для того чтобы создавать работающие программы, нужно не так уж много знать о самих ЭВМ. На самом элементарном уровне программирование - такое же ремесло, как плот- ничье или строительное дело, которому можно обучиться на практике, если только иметь к этому склонность. Разработчики систем и кустари-программисты так же не похожи друг на друга, как профессионалы (архитекторы и инженеры), проектирующие сложные здания, и домашние умельцы, своими руками мастерящие мебель, дачную постройку или жилой дом. Домашний умелец может выполнить всю работу от начала до конца, затратив минимум усилий на предварительное проектирование, принимая решения по ходу работы и доставая требуемые материалы (доски, кирпичи, гвозди и т. д.) по мере возникновения необходимости. Для успешного выполнения своей задачи домашнему умельцу не нужно обучаться основам архитектуры и конструирования. Программист-кустарь часто может руководствоваться методикой домашнего умельца, конструируя программу снизу вверх построчно и выбирая проектные решения по ходу работы. В некотором смысле его задача даже проще, чем у домашнего умельца, поскольку может и не понадобиться доставать новые материалы: достаточно мощная ЭВМ всегда предоставляет широкий набор стандартных блоков (машинных команд). Во многих случаях для успешного выполнения своей задачи программисту-кустарю не нужно обладать знаниями в области архитектуры и техники программного обеспечения. Однако и домашний умелец, и кустарный программист достигнут в конечном итоге тех предельных масштабов и сложности проекта, за которыми уже очень трудно или опасно про* должать работу без специальных знаний в соответствующих областях архитектуры и техники. Этот предел можно охарактеризовать как границу между кустарным и промышленным производством. Для промышленного производства характерно разнообразие технологий, специалистов и целей, что требует детальной проработки планов в любом проекте еще до начала его реализации. Таким образом, ясно, что предложенные в данной книге методы ориентированы на промышленное производство программного обеспечения. В то же время абсолютно справедливо считать, что составление подробного плана до начала выполнения работ помогает избежать ошибок и повышает производительноств труда при выполнении любого проекта. Таким образом, настоящая книга будет полезна и программистам, разрабатывающим программные средства кустарным способом. ].3.5. Программа как черный ящик: новаторская концепция Данная книга ориентирует читателя на то, чтобы он пред-* ставлял себе программное обеспечение в структурной форме, а не в виде блок-схемы или закодированных строк. В книге 0 1 2 3 4 5 [ 6 ] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 |