В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 6
Текст из файла (страница 6)
Для этого нужно учесть множество аспектов. Доходы от продаж значительноснизятся, если многие из пользователей не смогут воспользоваться программой толькопотому, что в их компьютерах процессоры слишком медленные или мало оперативнойпамяти, или потому что данные к системе часто поступают в искаженном виде и она неможет их обработать, или потому что они привыкли работать с графическим интерфейсом,а система требует ввода из командной строки, и т.п.Важно отметить, что практически полезная сложная программная система не обязательноявляется «правильной».12Большинство опытных разработчиков и исследователей считают, что практически значимыепрограммные системы всегда содержат ошибки. При переходе от «небольших» программ к«большим» понятие «правильной» программы становится практически бессмысленным. Пропрограммную систему, в отличие от приведенной выше программы вычисления числа π, нельзяутверждать, что она «правильная», т.е.
всегда правильно решает все поставленные перед нейзадачи. Этот факт связан как с практической невозможностью полного доказательства илипроверки этого, так и с тем, что смысл существования программной системы — удовлетворениепотребностей и запросов большого количества различных заинтересованных лиц. А этипотребности не только нечетко определены, различны для разных групп пользователей и иногдапротиворечивы, но и значительно изменяются с течением времени.В связи с этим, вместо рассмотрения «правильных» и «неправильных» программных систем, всилу практического отсутствия первых, рассматривают «достаточно качественные» и«недостаточно качественные».Поэтому и основные проблемы разработки сложных программных систем связаны снахождением разумного компромисса между затратами на разработку и качеством ее результата.В затраты входят все виды используемых ресурсов, из которых наиболее важны затрачиваемоевремя, бюджет проекта и используемый персонал.
Удовлетворение пользователей от работы спрограммой (а, следовательно, доходы от ее продаж и предоставления дополнительных услуг) иудовлетворение разработчиков от ее создания определяются качеством программы, котороевключает в себя такие аспекты, как набор предоставляемых возможностей, надежность, удобствоиспользования, гибкость, удобство внесения изменений и исправления ошибок. Более подробнопонятие качественного программного обеспечения будет обсуждаться в одной из следующихлекций.Часто программное обеспечение (ПО) нельзя рассматривать отдельно от программноаппаратной системы, куда оно входит в качестве составной части.
Изучением вопросов, связанныхс разработкой и эксплуатацией программно-аппаратных систем занимается системнаяинженерия. В ее рамки попадает огромное количество проблем, связанных с аппаратной частьюсистем и обеспечением нужного уровня интеграции программной и аппаратной составляющих.Мы только изредка будем затрагивать вопросы, касающиеся системной инженерии в целом, восновном ограничиваясь аспектами, относящимися непосредственно к ПО.В данном курсе будут рассматриваться различные подходы к решению проблем разработки,связанных с обеими составляющими дилеммы «ресурсы-качество» при создании сложныхпрограмм. Для изложения этих подходов вводится система понятий, относящихся к программнымсистемам и процессам их создания и позволяющих эффективно разрабатывать такие системы,оценивать и планировать их свойства.
В их число входят такие понятия, как жизненный цикл ПО,качество ПО, процесс разработки ПО, требования к ПО, архитектура ПО, образцыпроектирования и пр.Кроме того, особое внимание в курсе уделяется одному из подходов к разработке сложногоПО, компонентной разработке, предлагающей строить такие системы последовательно изотдельных элементов — компонентов, каждый из которых, в свою очередь, можетрассматриваться как отдельная программная система. Курс дает введение в современныекомпонентные технологии разработки программных систем на основе платформ J2EE и .NET.Проблемы, связанные с управлением ресурсами разработки, в том числе — планированиемотдельных действий во времени, созданием эффективных команд разработчиков, относятся куправлению проектами, которому будет посвящена последняя лекция курса.На основании опыта конструирования больших систем разработаны так называемыетехнологические процессы, содержащие достаточно детальные описания разных аспектов ихсоздания и эксплуатации.
Эти описания дают ответы на вопросы о том, как должна вестисьразработка, какие лица должны в ней участвовать и на каких этапах, какие виды деятельности и вкакой последовательности должны выполняться, какие документы являются их входнымиданными и какие документы, модели, другие части программной системы должны бытьподготовлены в результате каждой отдельной работы. Элементы таких методик будут13упоминаться на всем протяжении курса. Также будут рассматриваться отраслевые стандарты,содержащие описание выработанных на основе большого количества реальных проектов подходовк построению сложных программных систем.При практической разработке больших систем, однако, стоит помнить, что всеобщеметодические рекомендации имеют границы применимости, и чем детальнее они определяютдействия разработчиков, тем вероятнее, что что-то пойдет не так, как это предусматриваетсяавторами методик.
Кроме того, огромное количество вспомогательных по сути документов,оформление которых часто требуется подобными методиками, иногда затрудняет пониманиеосновных целей проекта, принимаемых в его ходе решений и сути происходящего в нем. Онотакже может приводить к имитации усердной работы при отсутствии реальных продвижений кнужным результатам.Протест сообщества разработчиков против подобной бюрократизации разработки программ ипопыток механического использования теоретических рекомендаций вылился в популярноесейчас движение живой разработки ПО (Agile Software Development).
Одним из примеров«живого» процесса разработки является набор техник, известный как экстремальноепрограммирование (Extreme Programming, XP). Некоторые аспекты этих подходов также будутрассмотрены в данном курсе.Принципы работы со сложными системамиПомимо методических рекомендаций, при конструировании больших систем частоиспользуются прагматические принципы работы со сложными системами вообще.
Они играютзначительную роль в выработке качественных технических решений в достаточно широкомконтексте. Эти принципы позволяют распределять работы между участвующими в проектахлюдьми с меньшими затратами на обеспечение их взаимодействия и акцентировать вниманиекаждого из участников на наиболее существенных для его части работы характеристиках системы.К таким принципам относятся использование абстракции и уточнения, модульная разработка ипереиспользование.• Абстракция (abstraction) и уточнение (refinement).Абстракция является универсальным подходом к рассмотрению сложных вещей.
Интеллектодного человека достаточно ограничен и просто не в силах иметь дело сразу со всемиэлементами и свойствами систем большой сложности. Известно, что человеку крайнетяжело держать в голове одновременно десяток-полтора различных мыслей, а всовременных системах число различных существенных аспектов доходит до сотен. Длятого чтобы как-то все-таки работать с такими системами, мы пользуемся своейвозможностью абстрагироваться, т.е. отвлекаться от всего, что несущественно длядостижения поставленной в данной момент частной цели и не влияет на те аспектырассматриваемого предмета, которые для этой цели важны.Чтобы перейти от абстрактного представления к более конкретному, используетсяобратный процесс последовательного уточнения.
Рассмотрев систему в каждом аспекте вотдельности, мы пытаемся объединить результаты анализа, добавляя аспекты по одному иобращая при этом внимание на возможные взаимные влияния и возникающие связи междуэлементами, выявленными при анализе отдельных аспектов.Абстракция и уточнение используются, прежде всего, для получения работоспособныхрешений, гарантирующих нужные свойства результирующей системы.Пример абстракции и уточнения.Систему хранения идентификаторов пользователей Интернет-магазина можно представитькак множество целых чисел, забыв о том, что эти числа — идентификаторы пользователей,и о том, что все это как-то связано с Интернет-магазином.Затем описанную модель системы хранения идентификаторов пользователей Интернетмагазина можно уточнить, определив конкретную реализацию множества чисел, например,на основе сбалансированных красно-черных деревьев (см.
[2], раздел 14, глава III и JDKклассы java.util.TreeSet и java.util.TreeMap).14•Другой пример.Рассматривая задачу передачи данных по сети, можно временно абстрагироваться отбольшинства проблем организации связи и заниматься только одним аспектом —организацией надежной передачи данных в нужной последовательности. При этом можнопредполагать, что мы как-то умеем передавать данные между двумя компьютерами в сети,хотя, быть может, и с потерями и с нарушением порядка их прибытия по сравнению спорядком отправки.
Установленные ограничения выделяют достаточно узкий набор задач.Любое их решение представляет собой некоторый протокол передачи данныхтранспортного уровня, т.е. нацеленный именно на надежную упорядоченную доставкуданных. Выбирая такой протокол из уже существующих, например, TCP, или разрабатываяновый, мы производим уточнение исходной общей задачи передачи данных.Другой способ уточнения — перейти к рассмотрению протоколов, обеспечивающихисходные условия для нашей первой абстракции, т.е. возможность вообще что-топередавать по сети. При этом возникают протоколы нижележащих уровней — сетевого(отвечают за организацию связи между не соединенными непосредственно компьютерамипри наличии между ними цепи машин, соединенных напрямую), канального (такиепротоколы отвечают за определение формата передаваемых данных и надежность передачиотдельных элементов информации между двумя физически соединенными компьютерами)и физического (отвечают за определение физического носителя передаваемого сигнала иправильность интерпретации таких сигналов обеими машинами, в частности, законкретный способ передачи битов с помощью электрических сигналов или радиоволн).Модульность (modularity).Модульность — принцип организации больших систем в виде наборов подсистем, модулейили компонентов.