Основные программные модули

Ada-программа состоит из одного или нескольких программных модулей. Программным модулем Ada 95 является:

q подпрограмма – определяет действия – подпроцесс (различают две разновидности: процедуру и функцию);

q пакет – определяет набор логически связанных описаний объектов и действий, предназначенных для совместного использования;

q задача – определяет параллельный, асинхронный процесс;

q защищенный модуль – определяет защищенные данные, разделяемые между несколькими задачами;

q родовой модуль – настраиваемая заготовка пакета или подпрограммы.

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

Как правило, модули можно компилировать отдельно. Обычно в модуле две части:

q спецификация (содержит сведения, видимые из других модулей);

q тело (содержит детали реализации, невидимые из других модулей).

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

Функции

Функция – разновидность подпрограммы, которая возвращает значение результата.

Спецификация функции имеет вид

function <ИмяФункции> (<СписокФормальныхПараметров>)

return <ТипРезультата>;

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

<ИмяПеременной>:<ТипДанных> := <ЗначениеПоУмолчанию>

Значение по умолчанию может не задаваться.

Пример спецификации:

function Box_Area (Depth : Float; Width : Float) return Float;

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

function <ИмяФункции> (<СписокФормальныхПараметров>)

return <ТипРезультата> is

<объявления локальных переменных и констант>

begin

<операторы>

return <результат>; -– оператор возврата результата

end <ИмяФункции>;

Пример тела функции:

function Box_Area (Depth : Float; Width ; Float) return Float is

Result : Float;

begin

Result := Depth * Width;

return Result: -– возврат вычисленного значения

end Box_Area;

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

<ИмяПеременной> := <ИмяФункции> (<СписокФактическихПараметров>);

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

Пример вызова:

Му_Вох := Вох_Агеа ( 2.0. 4.15 );

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

Процедуры

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

procedure <ИмяПроцедуры> (<СписокФормальныхПараметров>);

Для записи каждого формального параметра принят следующий формат:

<Имя> : <Вид> <Тип данных>;

где <Вид> указывает направление передачи информации между формальным и фактическим параметрами (in – передача из фактического в формальный параметр, out – из формального в фактический параметр, in out – двунаправленная передача).

ПРИМЕЧАНИЕ

Пометку in разрешается не указывать (она подразумевается по умолчанию), поэтому в спецификации функции вид параметра отсутствует. Для формального параметра вида in разрешается задавать начальное значение, присваиваемое по умолчанию.

Пример спецификации:

procedure Sum ( Opl : in Integer := 0; Op2 : in Integer := 0;

Op3 : in Integer := 0: Res : out Integer );

Тело процедуры в общем случае имеет вид

procedure <ИмяПроцедуры>

(<СписокФормальныхПараметров>) is

<объявления локальных переменных и констант>

begin

<операторы>

end <ИмяПроцедуры>;

Пример тела:

procedure Sum ( Opl : in Integer := 0; Op2 : in Integer := 0;

Op3 : in Integer := 0: Res : out Integer ) is

begin

Res := Opl + Op2;

Res := Res + Op3;

end Sum;

В данной процедуре три формальных параметра имеют значения по умолчанию. Это дает интересные возможности.

Обращаются к процедуре с помощью оператора вызова, он имеет вид

<ИмяПроцедуры> (<СписокФактическихПараметров>);

Примеры операторов вызова:

Sum (4. 8, 12. d); -– переменная d получит значение 24

Sum (4. 8. Res => d); -– переменная d получит значение 12

ПРИМЕЧАНИЕ

В первом операторе вызова задано 4 фактических параметра, во втором операторе – 3 фактических параметра. Во втором операторе использованы как традиционная (позиционная) схема, так и именная схема сопоставления формального и фактического параметров.

Пакеты

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

Спецификация пакета объявляет предлагаемые услуги, а тело содержит реализацию этих услуг.

Спецификация пакета записывается в виде

package <ИмяПакета> is

<объявления типов, переменных, констант>

<спецификации процедур и функций>

end <ИмяПакета>;

Пример спецификации:

package Рисование is

type Точка is array ( 1 .. 2 ) of Integer;

-– описание точки в прямоугольной системе координат

procedure Переход ( из : in Точка; в : in Точка );

-– переход из одной точки в другую точку

procedure Рисовать_Линию (от : in Точка; до : in Точка );

-– рисуется сплошная линия между заданными точками

procedure Рисовать_Пунктирную_Линию (от : in Точка: до ; in Точка );

-– рисуется пунктирная линия

end Рисование;

Данная спецификация предлагает клиентам один тип данных и три процедуры.

Тело пакета представляется в виде

package body <ИмяПакета> is

<объявления локальных переменных, констант. типов>

<тела процедур и функций>

end <ИмяПакета>;

Еще раз отметим, что содержание тела пакета клиентам недоступно.

Пример тела:

package body Рисование is

-– локальные объявления

procedure Переход ( из : in Точка: в : in Точка ) is

-– локальные объявления

begin

-– операторы

end Переход;

procedure Рисовать_Линию(от : in Точка: до ; in Точка) is

-– локальные объявления

begin

-– операторы

end Рисовать_Линию;

procedure Рисовать_Пунктирную_Линию ( от : in Точка;

до : in Точка ) is

-– локальные объявления

begin

-– операторы

end Рисовать_Пунктирную_Линию;

end Рисование:

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

Производные типы

Объявление производного типа имеет вид

type <ИмяПроизводногоТипа> is

new <ИмяРодительскогоТипа> [<ОграничениеРодительскогоТипа>];

где ограничение на значения родительского типа могут отсутствовать.

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

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

Например, пусть сделаны объявления:

type Integer is …; -– определяется реализацией

function "+" ( Left. Right : Integer ) return Integer;

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

type Length is new Integer;

-– function "+" ( Left. Right : Length ) return Length;

Здесь символ комментария (--) показывает, что операция «+» наследуется автоматически, то есть от программиста не требуется ее явное объявление. Любая из унаследованных операций может быть переопределена, то есть может быть обеспечена ее новая реализация. О такой операции говорят, что она перекрыта:

type Угол is new Integer;

function "+" ( Left. Right : Угол ) return Угол;

В этом примере для функции «+» обеспечена новая реализация (учитывается модульная сущность сложения углов).

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

По сравнению с родительским типом в производном типе:

q набор значений может быть сужен (за счет ограничений при объявлении);

q набор операций может быть расширен (за счет объявления операций в определяющем для производного типа пакете).

Примеры объявления производных типов:

type Год Is new Integer range 0 .. 2099;

type Этаж i s new Integer range 1 .. 100;

Если теперь мы введем два объекта:

А : Год;

В : Этаж;

и попытаемся выполнить присваивание

А := В;

то будет зафиксирована ошибка.

Подтипы

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

Подтип – это сочетание типа и ограничения на допустимые значения этого типа. Объявление подтипа имеет вид

subtype <ИмяПодтипа> is <ИмяТипа> range <Ограничение>;

Характерные особенности подтипов:

q подтип наследует все операции, которые определены для его типа;

q объект подтипа совместим с любым объектом его типа, удовлетворяющим указанному ограничению;

q содержательные роли объектов различных подтипов для одного типа аналогичны.

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

Например, если в программе объявлен перечисляемый тип День_Недели, то можно объявить подтип

subtype Рабочий_День is День_Недели range ПОНЕДЕЛЬНИК..ПЯТНИЦА;

При этом гарантируется, что объекты подтипа Рабочий_День будут совместимы с объектами типа День_Недели.

Расширяемые типы

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

Рассмотрим построение иерархии геометрических объектов. На вершине иерархии точка, имеющая два свойства (координаты X и Y):

type Точка Is tagged

record

Х_КоорД : Float;

Y_Koopfl : Float;

end record;

Другие типы объектов можно произвести (прямо или косвенно) от этого типа.

Например, можно ввести новый тип, наследник точки:

type Окружность is new Точка with -– новый теговый тип;

record

Радиус : Float;

end record;

Данный тип имеет три свойства: два свойства (координаты X и Y) унаследованы от типа Точка, а третье свойство (Радиус) нами добавлено. Дочерний тип Окружность наследует все операции родительского типа Точка, причем некоторые операции могут быть переопределены. Кроме того, для дочернего типа могут быть введены новые операции.

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

1. Боэм Б. У. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. 511 с.

2. Липаев В. В. Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993. 384 с.

3. Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.

4. Орлов С. А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, 2001. 327 с.

5. Чеппел Д. Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.

6. Abreu, F. В., Esteves, R., Goulao, M. The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics. Proceedings of the TOOLS'96. Santa Barbara, California 20 pp. July 1996.

7. Albrecht, A. J. Measuring Application Development Productivity. Proc. IBM Application Development Symposium, Oct. 1979, pp. 83-92.

8. Ambler, S. W. The Object Primer. 2^nd ed. Cambrige University Press, 2001. 541 pp.

9. Beck, K., and Cunningham, W. A Laboratory for Teaching Object-oriented Thinking. SIGPLAN Notices vol. 24 (10), October 1989, pp 1-7.

10. Beck, K. Embracing Change with Extreme Programming. IEEE Computer, Vol. 32, No. 10, October 1999, pp. 70-77.

11. Beck, K. Extreme Programming Explained. Embrace Change. Addison-Wesley, 1999.211pp.

12. Beck, K, Fowler, M. Planning Extreme Programming. Addison-Wesley, 2001. 156pp.

13. Beizer, B. Software Testing Techniques, 2^nd ed. New York: International Thomson Computer Press, 1990. 503 pp.

14. Beizer, B. Black-Box Testing: Techniques for Functional Testing of Software and Systems. New York: John Wiley & Sons, 1995. 320 pp.

15. Bieman, J. M. and Kang, B-K. Cohesion and Reuse in an Object-Oriented System. Proc. ACM Symposium on Software Reusability (SSR'95), pp. 259-262, April 1995.

16. Binder, R. V. Testing object-oriented systems: a status report. American Programmer 7 (4), April 1994, pp. 22-28.

17. Binder, R. V. Design for Testability in Object-Oriented Systems. Communications of the ACM, vol. 37, No 9, September 1994, pp. 87-101.

18. Binder, R. V. Testing Object-Oriented Systems. Models, Patterns, and Tools. Ad-dison-Wesley, 1999. 1298 pp.

19. Boehm, B. W. A spiral model of software development and enhancement. IEEE Computer, 21 (5), 1988, pp. 61-72.

20. Boehm, B. W. Software Risk Management: Principles and Practices. IEEE Software, January 1991: pp. 32-41.

21. Boehm, B. W. etal. Software Cost Estimation with Cocomo II. Prentice Hall, 2001. 502 pp.

22. Booch, G. Object-Oriented analysis and design. 2^nd Edition. Addison-Wesley, 1994. 590 pp.

23. Booch, G., Rumbaugh, J., Jacobcon, I. The Unified Modeling Language User Guide. Addison-Wesley, 1999. 483 pp.

24. Chidamber, S. R. and Kemerer, C. F. A Metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, vol. 20: 476-493. No. 6, June 1994.

25. Cockburn, A. Agile Software Development. Addison-Wesley, 2001. 220 pp.

26. Coplien, J. O. Multi-Paradigm Design for C++. Addison-Wesley, 1999. 297 pp.

27. DeMarco, Т.. Structured Analysis and System Specification. Englewood Cliffs, NJ: Prentice-Hall, 1979.

28. Fenton, N. E., Pfleeger S. L. Software Metrics: A Rigorous & Practical Approach. 2^nd Edition. International Thomson Computer Press, 1997. 647 pp.

29. Fowler, M. The New Methodology http://www.martinfowler.com, 2001.

30. Fowler, M. Is Design Dead? Proceedings of the XP 2000 conference, the Mediterranean island of Sardinia, 11 pp., June 2000.

31. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns. Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. 410 pp.

32. Graham, I. Object-Oriented Methods. Principles & Practice. 3^rd Edition. Addison-Wesley, 2001. 853 pp.

33. Halstead, M. H. Elements of Software Science. New York, Elsevier North-Holland, 1977.

34. Hatley, D., and Pirbhai, I. Strategies for Real-Time System Specification. New York, NY: Dorset House, 1988.

35. Henry, S. and Kafura, D. Software Structure Metrics Based on Information Flow. IEEE Transactions on Software Engineering, vol. 7, No. 5,pp. 510-518, Sept. 1981.

36. Highsmith, J. A. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing, 2000. 392 pp.

37. Highsmith, J. A. Extreme programming, e-business Application Delivery, vol. XII, No. 2; February 2000, pp 1-16.

38. Hitz, M., Montazeri, В. Measuring Coupling in Object-Oriented Systems. Object Currents, vol. 2: 17 pp., No 4, Apr 1996.

39. Jackson, M. A. Principles of Program Design. London: Academic Press, 1975.

40. Jacobcon, I., Booch, G., Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, 1999. 463 pp.

41. Jacobcon, I., Christerson, M., Jonsson, P., Overgaard, G. J. Object-Oriented Software Engineering. Addison-Wesley, 1993. 528 pp.

42. Jorgensen, P. C. and Erickson, C. Object Oriented Integration. Communications of the ACM, vol. 37, No 9, September 1994, pp. 30-38.

43. Kirani, S. and Tsai, W. T. Specification and Verification of Object-Oriented programs, Technical Report TR 94-64 Computer Science Department University of Minnesota, December 1994. 99 pp.

44. Kruchten, Phillipe B. The 4+1 View Model of Architecture. IEEE Software, Vol. 12 (6), November 1995, pp. 42-50.

45. Lorenz, M. and Kidd, J. Object-Oriented Software Metrics. Prentice Hall, 1994. 146pp.

46. Marick, B. Notes on Object-Oriented Testing. Part 1: Fault-Based Test Design. Testing Foundations Inc., 1995. 7 pp.

47. Marick, B. Notes on Object-Oriented Testing Part 2: Scenario-Based Test Design. Testing Foundations Inc., 1995. 4 pp.

48. Martin, Robert C. RUP/XP Guidelines: Test-first Design and Refactoring. Rational Software White Paper, 2000.

49. McCabe, T. J. A Complexity Measure. IEEE Transactions on Software Engineering, vol. 2: pp. 308-320. No.4, Apr 1976.

50. McGregor, J.D. and Korson, T.D. Integrated Object Oriented testing and Development Processes. Communications of the ACM, vol. 37, No 9, September 1994, pp. 59-77.

51. McGregor, J. D., Sykes, D. A. A Practical Guide to Testing Object-Oriented Software. Addison-Wesley, 2001. 407 pp.

52. Myers, G. Composite Structured Design. New York, NY: Van Nostrand Reinhold, 1978.

53. OMG Unified Modeling Language Specification. Version 1.4. Object Management Group, Inc., 2001.566pp.

54. Orr, K. T. Structured Systems Analysis. Englewood Cliffs, NJ: Yourdon Press, 1977.

55. Ott, L., Bieman, J. M., Kang, B-K., Mehra, B. Developing Measures of Class Cohesion for Object-Oriented Software. Proc. Annual Oregon Workshop on Software Merics (AOWSM'95). 11 pp., June 1995.

56. Oviedo, E. I. Control Flow, Data Flow and Program Complexity. Proc. IEEE COMPSAC,Nov. 1980, pp. 146-152.

57. Quatrani, T. Visual Modeling with Rational Rose and UML. Addison-Wesley, 1998. 222pp.

58. Page-Jones, M. The Practical Guide to Structured Systems Design. Englewood Cliffs, NY: Yourdon Press, 1988.

59. Page-Jones, M. Fundamentals of Object-Oriented Design in UML. Addison – Wesley, 2001. 479 pp.

60. Parnas, D. On the Criteria to the Be Used in Decomposing Systems into Modules. Communications of the ACM vol. 15 (12), December, 1972, pp. 1053-1058.

61. Paulk, M. C., B. Curtis, M. B. Chrissis, and C. V. Weber. Capability Maturity Model, Version 1.1. IEEE Software, 10, 4, July 1993, pp. 18-27.

62. Paulk, M. C. Extreme Programming from a CMM Perspective. XP Universe, Raleigh, NC, 23-25 July 2001, 8 pp.

63. Poston, R. M. Automated Testing from Object Models. Communications of the ACM, vol. 37, No 9, September 1994, pp. 48-58.

64. Pressman, R. S. Software Engineering: A Practioner's Approach. 5^th ed. McGraw-Hill, 2000. 943 pp.

65. Royce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9.

66. Rumbaugh J., Blaha M., Premerlani W., Eddy F. and Lorensen W. Object Oriented Modeling and Design. Prentice Hall, 1991. 500 pp.

67. Rumbaugh, J., Jacobcon, I., Booch, G., The Unified Modeling Language Reference Manual. Addison-Wesley, 1999. 567 pp.

68. Shalloway, A., Trott, J. R. Design Patterns Explained. A New Perspective on Object-Oriented Design. Addison – Wesley, 2002. 361 pp.

69. Sommerville, I. Software Engineering. 6^th ed. Addison-Wesley, 2001. 713 pp.

70. Stevens, W., Myers, G., and Constantine, L. 1979. Structured Design. IBM Systems Journal, Vol. 13(2), 1974, pp. 115-139.

71. Vliet, J. C. van. Software Engineering: Principles and Practice. John Wiley & Sons, 1993.558pp.

72. Tai, K., and Su, H. Test Generation for Boolean Expressions. Proc. COMPSAC'87, October 1987, pp. 278-283.

73. Ward, P., and Mellor, S. Structured Development for Real-Time Systems: Introduction and Tools. Vols. 1, 2, and 3. Englewood Cliffs, NJ: Yourdon Press, 1985.

74. Warnier, J. D. Logical Construction of Programs. New York: Van Nostrand Rein-hold, 1974.

75. Wells, J. D. Extreme Programming: A gentle introduction, http:// www.extreme-programming.org, 2001.

76. Wirfs-Brock, R., Wilkerson, В., and Wiener, L. Designing Object-oriented Software. Englewood Cliffs, New Jersey: Prentice Hall, 1990. 341 pp.

77. Yourdon, E., and Constantine, L. Structured Design: fundamentals of a discipline of computer program and systems design. Englewood Cliffs, NJ: Prentice-Hall, 1979.