Модульное программирование. Интеллектуальная собственность

    Челябинский юридический колледж

    Кафедра математических и  естественнонаучных дисциплин

      
 
 
 
 
 

    КУРСОВАЯ  РАБОТА

    по  дисциплине «Теория разработки программных  продуктов» 

    Модульное программирование. Интеллектуальная собственность 
 
 
 
 
 
 

    
 
 
 
 
 
 
 
 
 
 
 
 

    Челябинск

    2010

     Содержание 

Введение…………………………………………………………………………...3

1. Модульное программирование

1.1. Общее положение……………………………………………………………

1.2. Цель и характеристики………………………………………

1.3. Методы модульного  программирования……………………..

1.4. Контроль  структуры модульной программы…………………………

2. Интеллектуальная  собственность…………………………………………….

2.1. Общее положение…………………………………………………………….

2.2. Патент, правовые аспекты…..........................................................................

2.3. Интеллектуальная  собственность в software…………………………….

3. Практическая  часть. Программа «электронный  Дневник»

3.1. Описание

3.2. Разработка  и руководство

3.3. Заключение  по практической части.

Заключение……………………………………………………………………….

Список литературы……………………………………………………………… 
 
 
 
 
 

 

 

Введение

Целью данной курсовой работы является рассмотрение двух вопросов касающихся технологии разработки программных продуктов:

1. Модульное программирование
2. Интеллектуальная собственность

 

Первая  часть курсовой работы рассматривает  некоторые типы модульного программирования, его структуру и типы

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

Третья  часть рассматривает выбранный  мною продукт «Электронный дневник». Эта программа предназначена  для занесения ведения личных записей посредством ПК.

 

1. Модульное программирование

 

1. Общее положение 

 

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

      

     Модульное программирование. Основная идея заключается в том, чтобы "спрятать" данные и процедуры внутри независимых программных единиц - модулей. Эту идею впервые реализовал Н. Вирт в алгоритмическом языке Modula (1975-1979 годы), а затем "подхватили" и остальные, распространенные в то время языки программирования. Например, известные системы программирования Turbo Pascal и Turbo С.  
 
Необходимо указать ещё 2 ступени развития модульного программирования:

      

     Объектно-ориентированное программирование. Вскоре, необходимо было сделать не случайное объединение данных и алгоритмов их обработки в единое целое, а - смысловое. То есть необходимо было создать модульное программирование нового уровня, когда основной акцент делается на смысловую связь структур данных и алгоритмов их обработки. Сейчас практически все основные языки программирования (их более 100, в том числе такие распространенные, как Object Pascal, C++, Smalltalk) базируются на этой идее, а предком их является язык Simula, созданный еще в 1960 году.

     Обобщенные  технологии разработки приложений. Идеология объектно-ориентированного программирования породила CASE-технологии разработки и сборки программ на основе уже известных программных моделей, содержащих интерфейсы и прототипы (шаблоны — template) данных: COM (Component Object Model), STL (Standard Template Library), ATL (Active Template Library). Все эти новшества поддерживают визуальные среды разработки, например, такие известные, как Visual C++, Borland C++ Builder, Borland Delphi. 

     Теперь  подробно рассмотрим технологию модульного программирования. 

     1.2. Цель и характеристики.  
 

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

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

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

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

     Для воплощения первого метода формулируются  определенные требования, которым должен удовлетворять программный модуль, т.е. выявляются основные характеристики «хорошего» программного модуля.

     Для воплощения второго метода используют древовидные модульные структуры  программ (включая деревья со сросшимися ветвями). 
 
Характеристики модуля:

• размер модуля;
• прочность модуля;
• сцепление с другими модулями;
• рутинность модуля (независимость от предыстории обращений к нему).

 

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

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

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

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

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

      Сцепление модуля - это мера его зависимости по данным от других модулей. Характеризуется способом передачи данных. Чем слабее сцепление модуля с другими модулями, тем сильнее его независимость от других модулей. Для оценки степени сцепления был. предложен упорядоченный набор из шести видов сцепления модулей.

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

        Не рекомендуется использовать  также сцепление по общей области - это такое сцепление модулей, когда несколько модулей используют одну и ту же область памяти.

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

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

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