Языки программирования / Книги / ob''ektno-orientirovannyj_analiz_i_proektirovanie

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

пространственная сложность, space complexity. Относительный или абсолютный объем памяти, занимаемый объектом.

пространство состояний, state space. Перечислимое множество всех возможных состояний объекта. Пространство состояний программы содержит неопределенное, но конечное число состояний (не обязательно желаемых или ожидаемых).

протокол, protocol. Способы, которыми объекты могут действовать и реагировать; полное статическое и динамическое представление объекта; протокол объекта определяет допустимое поведение объекта.

процесс, process. Запуск одного потока управления.

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

прямой инжиниринг, forward-engineering. Создание исполнимого кода по логической или физической модели. Противопоставляется обратному инжинирингу.

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

реактивная система, reactive system. Система, движимая событиями. Поведение такой системы не определяется простым отображением "вход-выход".

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

роль, role. Способность или цель, с которой класс или объект участвует в отношениях с другими; некоторая четко выделяемая черта поведения объекта в определенный момент времени; роль - это лицо, которое объект являет миру в данный момент.

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

связь, link. Связь между объектами, экземпляр ассоциации.

селектор, selector. Операция, имеющая доступ к состоянию объекта, но не изменяющая его.

сервер, server. Объект, который никогда не воздействует на другие объекты, но используется ими; объект, предоставляющий некоторые услуги.

сигнатура, signature. Полная спецификация операции с указанием типов аргументов и возвращаемого значения.

сильно типизированный, strongly typed. Свойство языка программирования, в соответствии с которым во всех выражениях гарантируется согласованность типов.

синхронизация, synchronization. Семантика параллельности операции. Операция может быть простой (присутствует только один поток управления); синхронной (рандеву двух потоков); односторонняя (рандеву, при котором одному из потоков приходится ждать);по истечении времени (рандеву, в котором один процесс ждет другого определенное время); асинхронной (два процесса независимы друг от друга).

система реального времени, real-time system. Система, в которой некоторые существенные процессы должны укладываться в отведенное время. Система "жесткого" реального времени должна быть детерминированной; запаздывание с реакцией грозит катастрофой.

скрытие информации, information hiding. Процесс скрытия всех секретов объекта, которые ничего не добавляют к его существенным характеристикам; обычно скрывают структуру объекта и реализацию его методов.

словарь данных, data dictionary. Полный перечень всех классов в системе.

слой, layer. Совокупность категорий классов или подсистем одного уровня абстракции.

слот, slot. Часть состояния объекта; совокупность слотов образуют структуру объекта. Термины "поле", "переменная экземпляра", "объект-член" и "слот" означают одно и то же.

событие, event. Что-то, что может изменить состояние системы.

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

составной объект (агрегат), aggregate object. Объект, состоящий из других объектов (его частей).

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

сотрудничество, collaboration. Процесс, в котором несколько объектов сотрудничают для обеспечения требуемого поведения верхнего уровня.

сохраняемость, persistence. Способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из одного адресного пространства в другое.

среда разработки, framework. Набор классов, предоставляющих некоторые базовые услуги в определенной области. Таким образом, среда разработки экспортирует классы и механизмы, которые клиенты могут использовать или адаптировать.

статическое связывание, static binding. Связывание означает установление соответствия имени (например, объявленной переменной) классу. Статическое связывание происходит при объявлении имени (во время компиляции), до того, как объект будет создан.

страж, guard. Логическое выражение, применяемое к событию; если выражение истинно, то событие происходит и система изменяет состояние.

стратегическое проектное решение, strategic design decision. Проектные решения,

которые имеют решающее влияние на архитектуру.

структура классов, class structure. Граф, вершины которого соответствуют классам, а ребра - отношениям классов. Структура классов для конкретной системы представляется в виде совокупности диаграмм классов.

структура объектов, object structure. Граф, вершины которого соответствуют объектам, а ребра - отношениям объектов. Для отражения структуры объектов или ее части используются диаграммы объектов.

структура, structure. Конкретное представление состояния объекта. Каждый объект имеет собственное состояние, независимое от других объектов, хотя все объекты одного класса имеют одинаковое представление состояния.

структурное проектирование, structured design. Метод проектирования, основанный на алгоритмической декомпозиции.

суперкласс, superclass. Класс, которому наследуют другие классы (называемые непосредственными подклассами).

сценарий, scenario. Последовательность событий, выражающая некий аспект поведения системы.

тактическое проектное решение, tactical design decision. Проектное решение, имеющее ограниченное значение для архитектуры.

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

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

трансформационная система, transformational system. Система, поведение которой определяется в терминах отображения "вход-выход".

управление доступом, access control. Механизм доступа к данным и операциям класса. В C++ открытые элементы доступны всем, защищенные элементы доступны подклассам, так называемым друзьям класса и файлам реализации, закрытые элементы доступны реализации и друзьям класса. Наконец, элементы с доступом на уровне реализации доступны только в файле реализации класса.

уровень абстракции, level of abstraction. Относительное упорядочение абстракций по структурам классов, объектов, модулей или процессов. В терминах иерархии "часть/целое" объект находится на более высоком уровне абстракции, чем другие, если он строится на основе этих объектов: в терминах иерархии "общее/частное", высокоуровневые абстракции носят более обобщенный характер, чем низкоуровневые.

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

устройство, device. Часть аппаратуры, не имеющая собственных вычислительных ресурсов.

утверждение, assertion. Логическое выражение некоторого условия, истинность которого необходимо обеспечить.

утилита класса, class utility. Совокупность свободных подпрограмм. На C++ - класс, который состоит только из статических членов и/или функций-членов.

функциональная точка, function point. В контексте анализа требований к системе - отдельное поведение, видимое извне и поддающееся проверке.

функция, function. Некоторое преобразование "вход-выход", вытекающее из поведения объекта.

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

экземпляр, instance. Нечто, чем можно оперировать. Экземпляр имеет состояние, поведение и идентичность. Структура и поведение всех экземпляров класса определяются этим классом. Термины "объект" и "экземпляр" взаимозаменяемы.

Литературные ссылки

Предисловие

Mills, Н. 1985. DPMA and Human Productivity. Houscon, TX: Data Processing Management, Association.

Часть I. Концепции

Wagner, J. 1986. The Search for Signs of Intelligent Life in the Universe. New York, NY: Harper and Row, p.202. By permission of ICM. Inc.

Глава 1. Сложность

[1]Brooks, F. April 1987. No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer vol.20(4), p.12.

[2]Peters, L. 1981. Software Design. New York, NY: Yourdon Press, p.22.

[3]Brooks. No Silver Bullet, p.11.

[4]Parnas, D. July 1985. Software Aspects ofStrategic Defense Systems. Victoria, Canada: University of Victoria. Report DCS-47-IR.

[5]Peter, L. 1986. The Peter Pyramid. New York, NY: William Morrow, p.153.

[6]Waldrop, M. 1992. Complexity: The Emerging Science at the Edge of Order and Chaos. New-York, NY: Simon and Schuster.

[7]Courtois, P. June 1985. On Time and Space Decomposition of Complex Structures. Communications of the ACM vol.28(6), p.596.

[8]Simon, H. 1982. The Sciences of the Artificial. Cambridge, MA: The MIT Press, p.218.

[9]Rechtin, E. October 1992. The Art of Systems Architecting. IEEE Spectrum, vol.29( 10), p.66.

[10]Simon. Sciences, p.217.

[11]Ibid, р. 221.

[12]Ibid, p.209.

[13]Gall, J. 1986. Systemantics: How Systems Really Work and How They Fail. Second Edition. Ann Arbor, MI: the General Systemantics Press, p.65.

[14]Miller, G. March 1956. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Reviev vol.63(2), p.86.

[35]Miller. Magical Number, p.95.

[36]Shaw, M. 1981. ALPHARD: From and Content. New York, NY: Springer-Verlag, p.6.

[37]Goldberg, A. 1984. Smalltalft-80: The Interactive Programming Environment. Reading, MA: Addison-Wesley, p.80.

[38]Petroski, H. 1985. To Engineerls Human. St Martin's Press: New York, p.40.

[39]Dijkstra, E. January 1993. American Programmer vol.6(1).

[40]Mostow, J. Spring 1985. Toward Better Models of the Design Process. Al Magazine vol.6(1), p.44.

[41]Stroustrup, В. 1991. The C++ Programming Language. Second Edition. Reading, MA: Addison-Wesley, p.366.

[42]Eastman, N. 1984. Software Engineering and Technology. Technical Directions vol.10(1): Bethesda, MD: IBM Federal Systems Division, p.5.

[43]Brooks. No Silver Bullet, p.10.

Глава 2. Объектная модель

[1]Rentsch, Т. September 1982. Object-Oriented Programming. SIGPLAN Notices vol.17(12), p.51.

[2]Wegner, P. June 1981. The Ada Programming Language and Environment. Unpublished draft.

[3]Abbott, R. August 1987. Knowledge Abstraction. Communications of the ACM vol.30(8), p.664.

[4]Ibid, p.664.

[5]Shankar, K. 1984. Data Design: Types, Structures, and Abstractions. Handbook of Software Engineering. New York, NY: Van Nostrand Reinhold, p.253.

[6]Macintosh MacApp 1.1.1 Programmer's Reference. 1986. Cupertino, CA: Apple Computer, p.2.

[7]Bhaskar, K. October 1983. How Object-oriented Is Your System? SICPLAK Notices vol.18(10), p.8.

[8]Stefik, M. and Bobrow, D. Winter 1986. Object-oriented Programming: Themes and Variations, AI Magazine vol.6(4), p.41.

[9]Yonezawa, A. and Tokoro, M. 1987. ObjecE-Oriented Concurrent Programming. Cambridge, MA: The MIT Press, p.2.

[10]Levy, H. 1984. Capability-Based Computer Systems. Bedford, MA: Digital Press, p.13.

[11]Ramamoorthy, С. and Sheu, P. Fall 1988. Object-oriented Systems. IEEE Expert vol.3(3), p.14.

[12]Myers, G. 1982. Advances in Computer Architecture. Second Edition. New York, NY: John Wiley and Sons, p.58.

[13]Levy. Capability-Based Computer.

[14]Kavi, K. and Chen, D. 1987. Architectural Support for Object-oriented Languages. Proceedings of the Thirty-second IEEE Computer Society International Conference. IEEE.

[15]iAPX432 Object Primer. 1981. Santa Clara, CA: Intel Corporation.

[16]Dally, W.J. and Kajiya.J.T. March 1985. An Object-oriented Architecture, SIGARCH Newsletter vol.13(3).

[17]Dahlby, S., Henry, G., Reynolds, D. and Taylor, P. 1982. The IBM System/38: A High Level Machine, in Computer Structures: Principles and Examples. New York, NY: McGrawHill.

[18]Dijkstra. E. May 1968. The Structure of the "THE" Multiprogramming System. Communications of the ACM vol.11(5).

[19]Pashtan, A. 1982. Object-Oriented Operating Systems: An Emerging Design Methodology. Proceedings of the ACM'S2 Conference. ACM.

[20]Parnas, D. 1979. On the Criteria to the Be Used in Decomposing Systems into Modules, in Classics in Software Engineering. New York, NY: Yourdon Press.

[21]Liskov, B. and Zilles, S. 1977. An Introduction to Formal Specifications of Data Abstractions. Current Trends in Programming Methodology: Software Specification and Design vol.1. Englewood Cliffs. NJ: Prentice-Hall.

[22]Guttag, J. 1980. Abstract Data Types and the Development of Data Structures, in Programming Language Design. New York, NY: Computer Society Press.

[23]Shaw. Abstraction Techniques.

[24]Nygaard, K. and Dahl, O-J. 1981. The Development of the Simula Languages, in History of Programming Languages. New York, NY: Academic Press, p.460.

[25]Atkinson, M. and Buneman, P. June 1987. Types and Persistence in Database Programming Languages. ACM Computing Surveys vol.19(2), p.105.

[26]Rumbaugh, J. April 1988. Relational Database Design Using an Object-oriented Methodology. Communications of the ACM vol.31(4), p.415.

[27]Chen, P. March 1976. The Entity-Relationship Model - Toward a Unified View of Data. ACM Transactions on Database Systems vol.1(1).

[28]Barr,A.and Feigenbaum. E. 1981. The Handbook ofArtificial Intelligence. vol.1.Los Altos, CA: William Kaufmann, p.216.

[29]Stillings, N., Feinstein, M., Garfield.J., Rissland, E., Rosenbaum, D., Weisler. S., BakerWard, L. 1987. Cognitive Science: An Introduction. Cambridge, MA: The MIT Press, p.305.

[30]Rand, Ayn. 1979. Introduction to Objectivist Epistemology. New York, NY: New American Library.

[31]Minsky, M. 1986. The Society of Mind. New York, NY: Simon and Schuster.

[32]Jones, A. 1979. The Object Model: A Conceptual Tool for Structuring Software. Operating Systems. New York, NY: Springer-Verlag, p.8.

[33]Stroustrup, В. May 1988. What Is Object-oriented Programming? IEEE Software vol.5(3), p.10.

[34]Cardelli, L. and Wegner, P. On Understanding Types, Data Abstraction, and Polymorphism. December 1985. ACM Computing Surveys vol.17(4). p.481.

[35]DeMarco, T. 1979. Structured Analysis and System Specification. Englewood Cliffs, NJ: Prentice-Hall.

[36]Yourdon, E. 1989. Modem Structured Analysis. Englewood Cliffs, NJ: Prentice-Hall.

[37]Gane, C. and Sarson, T. 1979. Structured Systems Analysis. Englewood Cliffs, NJ:

Prentice-Hall.

[38]Ward, P. and Mellor, S. 1985. Structured Development for Real-Time Systems. Englewood Cliffs, NJ: Yourdon Press.

[39]Hatley, D. and Pirbhai, 1.1988. Strategies for Real-Time System Specification. New York, NY: Dorset House.

[40]Jenkins, M. and Glasgow, J. January 1986. Programming Styles in Nial. IEEE Software vol.3(1), p.48.

[41]Bobrow, D. and Stefik, M. February 1986. Perspectives on Artificial Intelligence Programming. Science vol.231, p.951.

[42]Dahl, O., Dijkstra, E. and Hoare, C.A.R. 1972. Structured Programming. London, England: Academic Press, p.83.

[43]Shaw, M. October 1984. Abstraction Techniques in Modern Programming Languages. IEEE Software vol.1(4), p.10.

[44]Berzins, V. Gray, M. and Naumann, D. May 1986. Abstraction-Based Software Development. Communications of the ACM vol. 29(5), p.403.

[45]Abelson, H. and Sussman, G. 1985. Structure and Interpretation of Computer Programs. Cambridge, MA: The MIT Press, p.126.

[46]Ibid, p.132.

[47]Seidewitz, E. and Stark, M. 1986. Towards a General Object-oriented Software Development Methodology. Proceedings of the First International Conference on Ada Programming Language Applications for the NASA Space Station. NASA Lyndon B.Johnson Space Center. TX: NASA, p.D.4.6.4.

[48]Meyer, B. 1988. Object-oriented Software Construction. New York. NY: Prentice-Hall.

[49]Wirfs-Brock. R. and Wilkerson, B. October 1989. Object-oriented Design: A Responsibility-Driven Approach. SICPLAN Notices vol.24(10).

[50]Ingalls, D. The Smalltalk-76 Programming System Design and Implementation. Proceedings of the Fifth Annual ACM Symposium on Principles of Programming Languages. ACM, p.9.

[51]Gannon.J., Hamlet. R. and Mills. H. July 1987. Theory of Modules. IEEE Transactions on Software Engineering vol.SE-13(7), p.820.

[52]Date, С. 1986. Relational Database: Selected Writings. Reading, MA: Addison-Wesley, p.180.

[53]Liskov, B. May 1988. Data Abstraction and Hierarchy. SIGPLAN Notices vol.23(5). p.19.

[54]Britton, K. and Parnas. D. December 8. 1981. A-7E Softs-are Module Guide. Washington, D.C. Naval Research Laboratory, Report 4702, p.24.

[55]Gabriel, R. 1990. Private Communication.

[56]Stroustrup, B. 1988. Private Communication.

[57]Myers. G. 1978. Composite/Structured Design. New York. NY: Van Nostrand Reinhold, p.21.

[58]Liskov, B. 1980. A Design Methodology for Reliable Software Systems, in Tutorial on Software Design Techniques. Third Edition. New York, NY: IEEE Computer Society, p.66.

[59]Zelkowitz, M. June 1978. Perspectives on Software Engineering. ACM Computing Surveys vol.10(2), p.20.

[60]Parnas, D., Clements, P. and Weiss, D. March 1985. The Modular Structure of Complex Systems. IEEE Transactions on Software Engineering vol.SE-11(3), p.260.

[61]Britton and Parnas. A-7E Software, p.2.

[62]Parnas. D., Clements, P. and Weiss, D. 1983. Enhancing Reusability with Information Hiding. Proceedings of the Workshop on Reusability in Programming. Stratford, CT: ITT Programming. p.241.

[63]Meyer. Object-oriented Software Construction, a. 47.

[64]Сох, В. 1986. Object-Oriented Programming: An Evolutionary Approach. Reading, MA: Addison-Wesley, p.69.