Разработка программных средств для решения экономических задач

Тема  5. Разработка программных средств для решения экономических задач

1. Общие принципы разработки программных средств

Определение общих принципов разработки программных  средств

Существуют следующие  общие принципы разработки программных  средств: частотный принцип, принцип  модульности, принцип функциональной избирательности, принцип генерируемости, принцип функциональной избыточности, принцип «по умолчанию».

Частотный принцип

Принцип основан на выделении  в алгоритмах и данных особых групп  по частоте использования. Для действий, наиболее часто встречающихся при  работе программ, создаются  условия их быстрого выполнения. К часто используемым данным  обеспечивается наиболее быстрый доступ. «Частые» операции стараются  делать более короткими. Следует отметить, что лишь не более 5 %  операторов программы оказывают ощутимое влияние на скорость  выполнения программы. Этот факт позволяет значительную часть  операторов программы кодировать без учета скорости вычислений,  обращая основное внимание при этом на «красоту» и наглядность текстов.

Принцип модульности

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

Принцип функциональной избирательности

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

Принцип генерируемости

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

Принцип функциональной избыточности

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

Принцип «по умолчанию»

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

Специфика разработки программных средств.

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

Жизненный цикл программного средства.

Под жизненным циклом ПС (software life cycle) понимают весь период его разработки и эксплуатации (использования), начиная  от момента возникновения замысла  ПС и кончая прекращением всех видов  его использования. Жизненный цикл охватывает довольно сложный процесс  создания и использования ПС (software process). Этот процесс может быть организован  по-разному для разных классов  ПС и в зависимости от особенностей коллектива разработчиков. 
В настоящее время можно выделить 5 основных подходов к организации процесса создания и использования ПС. 
• Водопадный подход. При таком подходе разработка ПС состоит из цепочки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС. 
• Исследовательское программирование. Этот подход предполагает быструю (насколько это возможно) реализацию рабочих версий программ ПС, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно приемлемо для пользователей. Такой подход применялся на ранних этапах развития программирования, когда технологии программирования не придавали большого значения (использовалась интуитивная технология). В настоящее время этот подход применяется для разработки таких ПС, для которых пользователи не могут точно сформулировать требования (например, для разработки систем искусственного интеллекта). 
• Создание портотипов. Этот подход моделирует начальную фазу исследовательского программирования вплоть до создания рабочих версий программ, предназначенных для проведения экспериментов с целью установить требования к ПС. В дальнейшем должна последовать разработка ПС по установленным требованиям в рамках какого-либо другого подхода (например, водопадного). 
• Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. На этом подходе базируется компьютерная технология (CASE-технология) разработки ПС. 
• Сборочное программирование. Этот подход предполагает, что ПС конструируется, главным образом, из компонент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми (reusable). Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования. 
В нашем курсе лекций мы, в основном, будем рассматривать водопадный подход с некоторыми модификациями. В рамках водопадного подхода различают следующие стадии жизненного цикла ПС (см. рис. 2.1): разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС.

1. Стадия разработки (development) ПС  состоит из этапа его внешнего  описания, этапа конструирования  ПС, этапа кодирования (программирование  в узком смысле) ПС и этапа  аттестации ПС. Всем этим этапам  сопутствуют процессы документирования  и управления (management) ПС. Этапы конструирования  и кодирования часто перекрываются,  иногда довольно сильно. Это означает, что кодирование некоторых частей  программного средства может  быть начато до завершения  этапа конструирования. 
- Этап внешнего описания ПС включает процессы, приводящие к созданию некоторого документа, который мы будем называть внешним описанием (requirements document) ПС. Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюдателя с фиксацией требований относительно его качества. Внешнее описание ПС начинается с анализа и определения требований к ПС со стороны пользователей (заказчика), а также включает процессы спецификации этих требований. 
- Конструирование (design) ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию. 
- Кодирование (coding) ПС включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС. 
- На этапе аттестации (acceptance) ПС производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то разработка ПС считается законченной. Это обычно оформляется в виде некоторого документа, фиксирующего решение комиссии, проводящей аттестацию ПС. 
2. Программное изделие (ПИ) экземпляр или копия разработанного ПС. Изготовление ПИ это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки. Стадия производства ПИ в жизненном цикле ПС является, по-существу, вырожденной (не существенной), так как представляет рутинную работу, которая может быть выполнена автоматически и без ошибок. Этим она принципиально отличается от стадии производства различной техники. В связи с этим в литературе эту стадию, как правило, не включают в жизненный цикл ПС. 
3. Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС. 
- Применение (operation) ПС это использование ПС для решения практических задач на компьютере путем выполнения ее программ. 
- Сопровождение (maintenance) ПС это процесс сбора информации качестве ПС в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях.

б. Модульное и объектно-ориентированное программирование

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

Роль модулей могут играть структуры данных, библиотеки функций, классы, сервисы и др. программные единицы, реализующие некоторую функциональность и предоставляющие интерфейс к ней.

Модульность программного кода

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

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

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

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

Создание модулей и использование  их объектов в программах является одним из приемов экономичного программирования, что обуславливается следующими обстоятельствами.

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

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

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

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

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

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

Модули служат также целям создания проблемно-ориентированного контекста  и локализации машинной зависимости.

Концепция модульного программирования

Концепцию модульного программирования можно сформулировать в виде нескольких понятий и положений:

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

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