внедрение

Инструмент, позволяющий использовать на листе Visio фрагменты, созданные в других приложениях. При этом редактирование таких фрагментов осуществляется в их "родном" приложении. Внедрение возможно только для приложений, поддерживающих технологию OLE 2.
Для внедрения в Visio фрагмента из другого зарегистрированного приложения выберите команду Insert > Object и в открывшемся окне диалога в списке выберите необходимое приложение. Чтобы внедрить фрагмент из уже созданного файла, в окне диалога Insert Object установите переключатель в положение Create from file и выберите необходимый файл. При работе с внедренным объектом меню и панели инструментов Visio замещаются соответствующими элементами внедряемого приложения, что позволяет производить редактирование данных во внедренном фрагменте, не выходя из Visio.
Документ Visio или его отдельные рисунки также могут быть внедрены в другие приложения, поддерживающие технологию OLE 2.

всплывающая подсказка

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


группа

Фигура, являющаяся композицией нескольких фигур. Число фигур в группе может варьироваться от одной до всех, имеющихся на листе.
Для группировки фигур их необходимо выделить и выбрать команду Shape > Grouping > Group. Фигура, получаемая в результате группировки, имеет все основные свойства обычной фигуры, сохраняя при этом и свойства входящих в ее состав фигур. Чтобы разгруппировать сгруппированную фигуру, нужно выбрать команду Shape > Grouping > Ungroup.


документ

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

документ: Обзор объектов(drawing explorer)

Обзор объектов в Visio 2000 осуществляется с помощью инструмента Drawing Explorer, позволяющего получить доступ или информацию обо всех объектах, имеющихся в текущем документе. По умолчанию этот инструмент представляет собой всплывающее окно, "прижатое" к одной из сторон окна редактирования.
Для открытия окна Drawing Explorer выберите команду View > Windows > Drawing Explorer.

документ: Режим представления

В Visio имеется два режима представления изображения: режим редактирования и режим электронной таблицы. Режим редактирования установлен по умолчанию и позволяет выполнять визуальное редактирование изображения. Режим электронной таблицы позволяет открыть для каждого объекта Visio - документа, листа, фигуры, мастера, стиля и т. д. - персональную электронную таблицу, в которой содержатся все необходимые параметры управления и настроек.
Для перехода к режиму электронной таблицы в окне Drawing Explorer выберите объект, для которого необходимо открыть электронную таблицу, щелкните по нему правой кнопкой мыши и в контекстном меню выберите команду Show ShapeSheet.

документ: Тип(file type)

Формат, к которому может быть преобразован документ Visio. Конвертация к типу, отличному от стандартного, выполняется в окне диалога Save As, которое открывается после выбора команды File > Save As. Раскрывающийся список File Type содержит все доступные для преобразования форматы.
Преобразование выполняется для использования созданных в Visio изображений в других приложениях, например в графических или Интернет-дизайнерских, или на тех компьютерах, где отсутствует приложение Visio 2000. Наиболее популярным форматом для преобразования является HTML-формат.

документ: Трафарет фигур(Document Stencil)

В Visio 2000 имеется отдельный трафарет Document Stencil, который содержит все фигуры, представленные на листах текущего документа. Его использование значительно облегчает создание однотипных рисунков, составляющие которых находятся в разных трафаретах. Чтобы открыть этот трафарет, выберите команду Window > Document Stencil. При добавлении из любого трафарета на лист новой, не используемой ранее фигуры она автоматически добавится в трафарет Document Stencil.


заливка (fill)

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


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

Введение

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

Основной задачей 90-х годов и начала XXI века стало совершенствование качества компьютерных приложений, возможности которых целиком определяются программным обеспечением (ПО).

Современный персональный компьютер теперь имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

Чрезвычайно актуальными стали следующие проблемы:

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

Ключом к решению этих проблем является грамотная организация процесса создания ПО, реализация технологических принципов промышленного конструирования программных систем (ПС).

Эта работа стремится к достижению трех целей:

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

Компьютерные науки вообще и программная инженерия в частности - очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века - информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства - 40%. Именно поэтому специальности направления "Компьютерные науки и информационные технологии" гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: "Кто владеет информацией - тот владеет миром!"

Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 - Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

    • Алфавитный указатель

    A

    Б

    В

    • Внедрение
    • Всплывающая подсказка

    Г

    • Группа

    Д

    • Документ
    • Документ: Обзор объектов(drawing explorer)
    • Документ: Режим представления
    • Документ: Тип (file type)
    • Документ: Трафарет фигур(Document Stencil)

    Е

    Ж

    З

    • Заливка (fill)

    И

    • Инструмент: Вспомогательный
    • Инструмент: Редактирования
    • Интерфейс

    К

    • Кодирование

    Л

    • Линейка (ruler)
    • Лист (page)

    М

    • Маркер: Вершины (vertices)
    • Маркер: Выделения (selection handle)
    • Маркер: Конечный (endpoint)
    • Маркер: Управления (control handle)
    • Мастер (master)
    • Масштаб (scale)

    Н

    О

    • Окно редактирования

    П

    • Панель инструментов (toolbar)
    • Привязка (guide, guide point)
    • Проводник Visio (shape explorer)
    • Проектирование
    • Предметная область

    Р

    • Рисунок: Тип (drawing type)

    С

    • Системный анализ
    • Сопровождение
    • Стратегии разработки П.О.
    • Свойства: Настраиваемые (custom property)
    • Связывание (link)
    • Сетка (grid)
    • Синхронная копия (synchronized copy)
    • Склеивание (glue)
    • Слой (layer)
    • Соединитель (connector)
    • Соединитель: От точки к точке (point-to-point)
    • Соединитель: От фигуры к фигуре (shape-to-shape)
    • Стиль (style)
    • Страница (page)

    Т

    • Тестирование
    • Текстовый блок (text block)
    • Точка соединения (connection point)
    • Точки данных (data points)
    • Трафарет (stencil)

    У

    • Узел сетки

    Ф

    • Фигура (shape)
    • Фигура: Выбранная (selection shape)
    • Фигура: Гиперссылка на страницу (off-page reference)
    • Фон (background)
    • Формат (format)

    Х

    Ц

    • Цветовая схема (color scheme)

    Ч

    Ш

    • Шаблон (template)

    Щ

    Э

    Ю

    Я


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

    • Введение

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

    Основной задачей 90-х годов и начала XXI века стало совершенствование качества компьютерных приложений, возможности которых целиком определяются программным обеспечением (ПО).

    Современный персональный компьютер теперь имеет производительность большой ЭВМ 80-х годов. Сняты практически все аппаратные ограничения на решение задач. Оставшиеся ограничения приходятся на долю ПО.

    Чрезвычайно актуальными стали следующие проблемы:

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

    Ключом к решению этих проблем является грамотная организация процесса создания ПО, реализация технологических принципов промышленного конструирования программных систем (ПС).

    Эта работа стремится к достижению трех целей:

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

    Компьютерные науки вообще и программная инженерия в частности - очень популярные и стремительно развивающиеся области знаний. Обоснование простое: человеческое общество XXI века - информационное общество. Об этом говорят цифры: в ведущих странах занятость населения в информационной сфере составляет 60%, а в сфере материального производства - 40%. Именно поэтому специальности направления "Компьютерные науки и информационные технологии" гарантируют приобретение наиболее престижных, дефицитных и высокооплачиваемых профессий. Так считают во всех развитых странах мира. Ведь не зря утверждают: "Кто владеет информацией - тот владеет миром!"

    Поэтому понятно то пристальное внимание, которое уделяет компьютерному образованию мировое сообщество, понятно стремление унифицировать и упорядочить знания, необходимые специалисту этого направления. Одними из результатов такой работы являются международный стандарт по компьютерному образованию Computing Curricula 2001 - Computer Science и международный стандарт по программной инженерии IEEE/ACM Software Engineering Body of Knowledge SWEBOK 2001.


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

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

    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. 2nd 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. 156 pp.
    13. Beizer, B. Software Testing Techniques, 2nd 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.1298pp.
    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. 2nd 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. 2nd 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. 3rd 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. 5th 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. 6th 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. 558 pp.
    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.


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

    • Общие вопросы разработки

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

    Определение технологии конструирования программного обеспечения

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

    Различают методы, средства и процедуры ТКПО.

    Методы обеспечивают решение следующих задач:

    • планирование и оценка проекта;
    • анализ системных и программных требований;
    • проектирование алгоритмов, структур данных и программных структур;
    • кодирование;
    • тестирование;
    • сопровождение.

    Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как

    Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

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

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

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

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

    Рассмотрим наиболее популярные парадигмы ТКПО.

    Классический жизненный цикл разработки

    Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970) [65].

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

    Охарактеризуем содержание основных этапов.

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

    Системный анализ (object analysis)

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

    • Анализ предметной области
    • Определение взаимодействия элементов системы между собой
    • Определение взаимодействия элементов с внешней средой(пользователи, аппаратура, другие программы -)
    • Планирование проекта разработки
      • Объем работ
      • График работ
      • Риски
      • Бюджет
      • Ресурсы

    Анализ требований ( requirements analysis)

    Анализ требований относится к программному элементу - программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

    Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

    • Формализация требований к разрабатываемой системе
    • Описание функциональности системы
    • Описание интерфейсов системы
    • Описание других желаемых характеристик :
      • Время реакции
      • Надежность
      • Открытость
      • Документация
      • Инвариантность
    • Составление плана v графика проекта

    Проектирование (design)

    • Создание архитектуры системы
    • Описание модульной структуры системы
    • Задание алгоритмической структуры
    • Задание структуры данных
    • Описание входного интерфейса
    • Описание выходного интерфейса (выходные формы).

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

    Кодирование

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

    Тестирование

    Выявление ошибок и дефектов в логике, функциях и форме реализации системы.

    Сопровождение

    Эксплуатация системы и внесение в нее изменений в процессе эксплуатации с целью:

    • исправление обнаруженных ошибок;
    • адаптация к изменениям условий эксплуатации;
    • усовершенствование отдельных характеристик.

    Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.

    Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.

    Недостатки классического жизненного цикла:

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

    Упражнение

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

    Начнем анализ:

    • Какой штрих - код будет использоваться ?
    • Какова номенклатура товара ?
    • Какое оборудование используем для считывания штрих кода ?
    • -

    Какие еще вопросы нужно задать ?

    Предложите пять

    Опишем объекты:

    Объект 1Товар

    Характеристиками этого объекта являются: ???

    Объект 2Пользователь

    Характеристиками его являются ???

    Еще объекты ???

    А связи между объектами-

    Анализ требований:

    • Требования ктовару и его штрих коду:
      • Штрих код однозначно задает товар
      • Штрих код сформирован по стандарту EAN13
    • Требования к функциональности
      • Штрих код должен считываться с расстояния до 30 мм
      • Должна поддерживаться номенклатура до 5000 наименований
    • Требования к интерфейсу
      • Интерфейс должен быть на русском языке
      • Программа должна работать с типами интерфейса сканеров: RS232,RS485,USB
      • Должна быть предусмотрена возможность вывода на печать списка товаров с их штрих кодами
    • Прочие требования к системе.
      • Программа должна иметь возможность вызова из внешнихприложений

    Проектируем:

    Заказчики, руководители, пользователи, разработчики должны:

    • Понять, что делает система
    • Понять общий принцип работы системы
    • Иметь возможность расширить систему
    • Повторно использовать часть системы в другом месте.

    Стратегии разработки ПО

    Характеристики стратегий в соответствии со стандартом IEEE/EIA 12207.2:

    Стратегия | В начале определены все требования | Множество циклов конструирования | Есть промежуточное ПО
Водопадная | ДА | НЕТ | НЕТ
Инкрементная | ДА | ДА | Может
Эволюционная | НЕТ | ДА | ДА

    Водопадная

    Линейная последовательность этапов. Каждый этап проходится 1 раз.

    Инкрементная

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

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

    Забегая вперед, отметим, что современная реализация инкрементного подхода - экстремальное программирование ХР. Оно ориентировано на очень малые приращения функциональности.

    Инкрементная стратегия:

    • Инкрементная модель
    • RAD модель
    • Модель экстремального программирования XP процесс

    RAD модель:

    Модель быстрой разработки приложений ( Rapid Application Development) - второй пример применения инкрементной стратегии конструирования (рис. 1.5).

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

    • бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?
    • моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;
    • моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;
    • генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;
    • тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы.. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

    ХP процесс:

    • Игра планирования (Planning game )
    • Смена версий (Small release)
    • Метафора (Metaphor)
    • Простое проектирование (Simple Design)
    • Непрерывное тестирование (Testing)
    • Реорганизация (Refactoring)
    • Парное программирование (Pair programming)
    • Коллективное владение кодом(Collective ownership)
    • Непрерывная интеграция (Continuous integration)
    • Стандартная неделя (40 hour week)
    • Локальный заказчик (On-site customer)
    • Стандарты программирования (Coding standards)

    Эволюционная

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

    Эволюционная стратегия:

    • Спиральная модель

    Достоинства спиральной модели:

    Наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

    Позволяет явно учитывать риск на каждом витке эволюции разработки;

    Включает шаг системного подхода в итерационную структуру разработки;

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

    Недостатки спиральной модели:

    Новизна (отсутствует достаточная статистика эффективности модели);

    Повышенные требования к заказчику;

    Трудности контроля и управления временем разработки.

  • Компонентно-ориентированная модель

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

    Достоинства компонентно-ориентированной модели:

    • уменьшает на 30% время разработки программного продукта;
    • уменьшает стоимость программной разработки до 70%;
    • увеличивает в полтора раза производительность разработки.
  • Объектно-ориентированная модель

    Стандарты

    ISO 9001:2000

    Общий стандарт процесса разработки

    ISO/IEC 155041 v 9 : 1998

    Специализированный стандарт процессов разработки программного обеспечения

    ISO 12207:

    1995 (ГОСТ Р 1999)

    Процессы жизненного цикла программных средств

    ISO 14598:

    1998 -2000

    Оценивание программного продукта

    ISO 14764:

    1999

    Сопровождение программных средств

    ISO 15910:1999

    Пользовательская документация программных средств

    ISO14102:1995

    Оценка и выбор CASEсредств

    ISO15846:1999

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


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

    • Rational Unified Process

    Слово "программист" в современном мире уже не должно поражать воображение и рождать в голове образ посвящённого энтузиаста, героя одиночки, который "колдует" у экрана монитора. Слова "компьютер" и "информация" вошли в бытовую речь. Сейчас уже можно говорить о переходе от индустриального общества к информационному, о котором в середине прошлого века размышлял основоположник кибернетики Н. Виннер. В этих условиях программист - это она из множества профессий, человек, член комманды разработчиков программного обеспечения (ПО) со своим устоявшимся образом жизни. Компьютерная программа в свою очередь - зто экономический продукт, котрый производит эта комманда, объект купли-продажи.
    Rational Unified Process (RUP) - новейшая технология в области разработки программных систем .
    Основная идея методов и средств RUP заключается в применении инженерного подхода к проектированию ПО, которое понимается как процесс создания проекта программного продукта, во многом аналогичный процессу создания промышленной продукции.

    #1 Итерационный подход к разработке

    RUP предлагает разработчикам не жесткие правила, регламентирующие выполнение всех действий в ходе разработки, а набор достаточно гибких методов и подходов, из которых разработчик может выбирать то, что более всего соответствует его задачам и особенностям проекта.
    Основными принципами RUP являются итерационная разработка, управление процессом на основе прецедентов использования и ориентация на архитектуру.
    Rational Unified Process ў это итерационный процесс. Создавать современные сложные программные системы последовательно, т.е. сначала определять все проблемы, затем принимать все проектные решения, формировать программные системы (ПС) и, наконец, проверять изделие, невозможно. Такой подход (называемый каскадным подходом или Lводопадом¦) в современной информационной индустрии не оправдывает себя, поскольку его использование часто приводит к непредсказуемому увеличению проектной стоимости и сроков выпуска ПС. Эффективной альтернативой Lводопаду¦ служит итерационный процесс разработки ПС. (Рис.1.)
    При итерационном процессе каждая из фаз процесса разработки ПС состоит из итераций, целью которых является последовательное осмысление стоящих проблем, наращивание эффективности решений и снижение риска потенциальных ошибок в проекте. На выходе каждой итерации создается законченная версия работающего программного продукта.
    При таком подходе можно гибко учитывать новые требования или производить тактические изменения в деловых целях, такой подход позволяет выявлять проблемы и разрешать их на самых ранних этапах разработки, что связано с меньшими затратами.

    Рис.1. Итерационный подход к разработке.

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

    #2 Технология RUP.

    Технология RUP (Rational Unified Process) разработана компанией Rational Software. Она ориентирована на использование универсального языка объектно-ориентированного моделирования UML, являющегося фактическим стандартом в данной области. На рис. 2 показан общий вид процесса RUP в двух измерениях:

    Рис. 2. Общий вид процесса RUP

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

    #2.1 Динамический аспект

     Согласно технологии RUP жизненный цикл ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта. Каждый цикл, в свою очередь, разбивается на четыре последовательные стадии:
  • начальная стадия (inception);
  • стадия уточнения (elaboration);
  • стадия конструирования (construction);
  • стадия ввода в действие (transition).
    Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.
    Первыми двумя стадиями являются начальная стадия проекта и уточнение.

    Начальная стадия (inception).

     Она может принимать множество разных форм. Для крупных проектов начальная стадия может вылиться во всестороннее изучение всех возможностей реализации проекта, которое займет месяцы. Во время начальной стадии вырабатывается бизнес-план проекта - определяется, сколько приблизительно он будет стоить и какой доход принесет. Устанавливаются также границы проекта, и выполняется некоторый начальный анализ для оценки размеров проекта.
    Для того чтобы проделать такую работу, необходимо идентифицировать все внешние сущности (действующие лица), с которыми система будет взаимодействовать, и определить в самом общем виде природу этого взаимодействия. Это подразумевает идентификацию всех вариантов использования use case, и описание наиболее важных из них. Бизнес-план включает критерии успеха, оценку риска, оценку необходимых ресурсов и общий план по стадиям, включающий даты основных контрольных точек.
    Результатами начальной стадии являются:
  • общее описание системы (основные требования к проекту, его характеристики и ограничения);
  • начальная диаграмма вариантов использования (степень готовности - 10 - 20%);
  • начальный проектный глоссарий (словарь терминов);
  • начальный бизнес-план;
  • план проекта, отражающий стадии и итерации;
  • один прототип или несколько.

    Стадия уточнения (elaboration).

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

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

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

    Стадия конструирования (construction).

     RUP представляет собой итеративный и пошаговый процесс разработки, в котором программное обеспечение разрабатывается и реализуется по частям. На стадии конструирования построение системы выполняется путем серии итераций. Каждая итерация является своего рода мини-проектом. На каждой итерации для конкретных вариантов использования выполняются анализ, проектирование, кодирование, тестирование и интеграция. Итерация завершается демонстрацией результатов пользователям и выполнением системных тестов в целях контроля корректности реализации вариантов использования.
    Назначение этого процесса состоит в снижении степени риска. Причиной появления риска зачастую является откладывание решения сложных проблем на самый конец проекта. Тестирование и интеграция - это достаточно крупные задачи, они всегда занимают больше времени, чем ожидается. Чем позже выполнять тестирование и интеграцию, тем более трудными задачами они становятся и тем более способны дезорганизовать весь проект. При итеративной разработке на каждой итерации выполняется весь процесс, что позволяет оперативно справляться со всеми возникающими проблемами.
    Итерации на фазе конструирования являются одновременно инкрементными и повторяющимися. Итерации являются инкрементными в соответствии с той функцией, которую они выполняют. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций. Итерации являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким.
    Процесс интеграции должен быть непрерывным. В конце каждой итерации должна выполняться полная интеграция. С другой стороны, интеграция может и должна выполняться еще чаще. Приложения следует интегрировать после выполнения каждой сколько-нибудь значительной части работы. Во время каждой интеграции должен выполняться полный набор тестов.
    Главная особенность итеративной разработки заключается в том, что она жестко ограничена временными рамками, и сдвигать сроки недопустимо. Исключением может быть перенос реализации каких-либо вариантов использования на более позднюю итерацию по соглашению с заказчиком. Смысл таких ограничений - поддерживать строгую дисциплину разработки и не допускать переноса сроков.
    При этом если на более поздний срок перенесено слишком много вариантов использования, то необходимо корректировать план, пересмотрев при этом оценку трудоемкости реализации вариантов использования. На данной стадии разработчики должны иметь более глубокое представление о такой оценке.
    Помимо конструирования итерации могут присутствовать во всех стадиях, однако при этом конструирование является ключевой стадией.
    Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Как минимум, он содержит следующее:
  • ПО, интегрированное на требуемых платформах;
  • руководства пользователя;
  • описание текущей реализации.

    Стадия ввода в действие (transition).

     Назначение этой стадии - передача готового продукта в распоряжение пользователей. Данная стадия включает:
  • бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;
  • параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;
  • конвертирование баз данных;
  • оптимизацию производительности;
  • обучение пользователей и специалистов службы сопровождения.
    Главная идея итеративной разработки - поставить весь процесс разработки на регулярную основу с тем, чтобы команда разработчиков смогла получить конечный продукт. Однако есть некоторые процессы, которые не следует выполнять слишком рано, например оптимизация.
    Оптимизация снижает прозрачность и расширяемость системы, однако повышает ее производительность. В этой ситуации необходимо принятие компромиссного решения, поскольку система должна быть достаточно производительной, чтобы удовлетворять пользовательским требованиям. Слишком ранняя оптимизация затруднит последующую разработку, поэтому ее следует выполнять в последнюю очередь.
    На стадии ввода в действие продукт не дополняется никакой новой функциональностью (кроме самой минимальной и абсолютно необходимой). Здесь только вылавливаются ошибки. Хорошим примером для стадии ввода в действие может служить период времени между выпуском бета-версии и окончательной версии продукта.

    #2.2 Статический аспект.

     Статический аспект RUP характеризуют четыре основных элемента:
  • исполнители;
  • действия;
  • результаты деятельности;
  • рабочие процессы.

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

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

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

    В рамках RUP определены шесть основных процессов:

  • построение бизнес-моделей (business modeling);
  • определение требований (requirements);
  • анализ и проектирование (analysis and design);
  • реализация (implementation);
  • тестирование(test);
  • развертывание(deployment)

    и три вспомогательных процесса:

  • управление конфигурацией и изменениями (configuration & сhange management);
  • управление проектом (project management);
  • создание инфраструктуры (environment).

    #3 Комплекс Rational Suite.

    RUP как продукт входит в состав комплекса Rational Suite, причем каждый из перечисленных выше процессов поддерживается определенным инструментальным средством комплекса. RUP состоит из базы знаний и руководства в твердой копии.
    База знаний включает следующие компоненты:

  • руководства для всех участников проектной команды, охватывающие весь жизненный цикл ПО. Руководства представлены в двух видах - для осмысления процесса на верхнем уровне и в виде подробных наставлений по повседневной деятельности;
  • наставления по использованию инструментальных средств, входящих в состав Rational Suite;
  • примеры и шаблоны проектных решений для Rational Rose;
  • шаблоны проектной документации для SoDa;
  • шаблоны в формате Microsoft Word, предназначенные для поддержки документации по всем процессам и действиям жизненного цикла ПО;
  • планы в формате Microsoft Project, отражающие итерационный характер разработки ПО.

    Адаптация RUP к потребностям конкретной организации или проекта обеспечивается с помощью специального набора инструментов и шаблонов Development Kit. База знаний имеет формат гипертекста (Рис.3) (HTML - HyperText Markup Language - стандартный язык для создания страниц Интернет). Доступ к ней может осуществляться с помощью Microsoft Internet Explorer или Netscape Navigator. Такой формат допускает как индивидуальное, так и коллективное использование базы знаний в сети Интранет.

    Рис. 3. База знаний в формате HTML.


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги
      • Диаграммы структурного системного анализа
      Диаграммы "сущность-связь"
      Диаграммы функционального моделирования
      Диаграммы потоков данных.

    Структурное проектирование

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

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

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

    Примечание
     Принято считать, что сам термин алгоритм происходит от имени средневекового математика Аль-Хорезми, который в 825 г. описал правила выполнения арифметических действий в десятичной системе счисления.

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

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

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

    Важным свойством таких программ является необходимость завершения всех действий предшествующей процедуры для начала действий последующей процедуры. Изменение порядка выполнения этих действий даже в пределах одной процедуры потребовало включения в языки программирования специальных условных операторов типа if-then-eise и Goto для реализации ветвления вычислительного процесса в зависимости от промежуточных результатов решения задачи.

    Рис. 1.0. Графическое представление программы
    в виде последовательности процедур

    Примечание
    Появление и интенсивное использование условных операторов и оператора безусловного перехода стало предметом острых дискуссий среди специалистов по программированию. Дело в том, что бесконтрольное применение в программе оператора безусловного перехода goto способно серьезно осложнить понимание кода. Соответствующие программы стали сравнивать со спагетти, называя их bowl of spaghetti, имея в виду многочисленные переходы от одного фрагмента программы к другому, или, что еще хуже, возврат от конечных операторов программы к ее начальным операторам. Ситуация казалась настолько драматичной, что в литературе зазвучали призывы исключить оператор goto из языков программирования. Именно с этого времени принято считать хорошим стилем программирования - программирование без goto.
    Рассмотренные идеи способствовали становлению некоторой системы взглядов на процесс разработки программ и написания программных кодов, которая Получила название методологии структурного программирования. Основой данной методологии является процедурная декомпозиция программной системы и организация отдельных модулей в виде совокупности выполняемых процедур. В рамках данной методологии получило развитие нисходящее проектирование программ или программирование "сверху-вниз". Период наибольшей популярности идей структурного программирования приходится на конец 70-х-начало 80-х годов.
    Как вспомогательное средство структуризации программного кода было рекомендовано использование отступов в начале каждой строки, которые должны выделять вложенные циклы и условные операторы. Все это призвано способствовать пониманию или читабельности самой программы. Данное правило со временем было реализовано в современных инструментариях разработки программ. Ниже приводится пример листинга программы на языке Pascal, который иллюстрирует эту особенность написания программ.

    Листинг 1.1. Пример фрагмента программы на Pascal, разработанной
    с использованием правил структурного программирования

    Procedure FirstOpt;

  Begin

    FuncRaz(Free, Rn);

    for i:=l to N do

      RvarRec[i]:= Rn[i];

    FvarRec:= Freс;

    Numlt:=0;

    Repeat

      NumIt:=NumIt+l;

      V:= Freс;

        for j:=1 to К do

          for 1:=1 to M do

            begin

              S:=0.0;

              T:=0.0;

              for i:=l to N do

                begin

                  T:=T+sqr(Wl[i,j])*Xpr[i,l];

                  S:=S+sqr(Wl[i,j])

                end;

              Zentr[j,l]:=T/S

            end;

          for j:=1 to К do

            for i:=l to N do

              begin

                S:=0.0;

                P:=0.0;

                Q:=0.0;

                for l:=1 to M do

                  S:=S+sqr(Xpr[i,l]-Zentr[j,l]);

                P:=1.0/S;

              end;

            Q:=0.0;

            D:=0;

            for i:=1 to N do

              for j:=1 to К do

                if Abs(Wl[i,j]-W2[i,j]) >= Eps then D:=l;

              for i:=l to N do

                for j:=1 to К do

                  W1[i,j]:=W2[i,j]

  Until (D=0)or(NumIt=NumMax)

End;

    В этот период основным показателем сложности разработки программ считали ее размер. Вполне серьезно обсуждались такие оценки сложности программ, как количество строк программного кода. Правда, при этом делались некоторые предположения относительно синтаксиса самих строк, которые должны были удовлетворять определенным правилам. Общая трудоемкость разработки программ оценивалась специальной единицей измерения - "человеко-месяц" или "человеко-год". А профессионализм программиста напрямую связывался с количеством строк программного кода, который он мог написать и отладить в течение, скажем, месяца.
    Примечание
    Сейчас попытки оценить профессионализм программиста количеством строк программного кода могут вызвать лишь улыбку собеседника. Действительно, используя встроенные мастера современных инструментариев разработки (MS Visual C++ или Inprise/Borland Delphi), даже новичок может за считанные секунды последовательным нажатием кнопок диалоговых меню создать работоспособное приложение, содержащее сотни строк программного кода и состоящее из десятка отдельных файлов проекта.

    Диаграммы структурного системного анализа

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

    Система - некоторая совокупность объектов, которые обладают следующим набором свойств :
    • Делимость
    • Связность - объекты, элементы системы связаны
    • Упорядоченность - связи между объектами упорядочены по определенному правилу
    • Интегральность - система обладает новой характеристикой, которой не обладает ни один элемент системы
    Под структурным системным анализом принято понимать метод исследования системы, который начинается с наиболее общего ее описания с последующей детализацией представления отдельных аспектов ее поведения и функционирования. При этом общая модель системы строится в виде некоторой иерархической структуры, которая отражает различные уровни абстракции с ограниченным числом компонентов на каждом из уровней. Одним из главных принципов структурного системного анализа является выделение на каждом из уровней абстракции только наиболее существенных компонентов или элементов системы.
    В рамках данного направления программной инженерии принято рассматривать три графические нотации, получивших названия диаграмм: диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD), диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT) и диаграммы потоков данных (Data Flow Diagrams, DFD).

    Диаграммы "сущность-связь"

    Данная нотация была предложена П. Ченом (P. Chen) в его известной работе 1976 года и получила дальнейшее развитие в работах Р. Баркера (R. Barker). Диаграммы "сущность-связь" (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают некоторый набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними, имеющих важное значение для разрабатываемой системы.
    Основными понятиями данной нотации являются понятия сущности и связи. При этом под сущностью (entity) понимается произвольное множество реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. В этом случае каждый рассматриваемый объект может являться экземпляром одной и только одной сущности, должен иметь уникальное имя или идентификатор, а также отличаться от других экземпляров данной сущности.
    Примерами сущностей могут быть: банк, клиент банка, счет клиента, аэропорт, пассажир, рейс, компьютер, терминал, автомобиль, водитель. Каждая из сущностей может рассматриваться с различной степенью детализации и на различном уровне абстракции, что определяется конкретной постановкой задачи. Для графического представления сущностей используются специальные обозначения (рис. 1.1).

    Рис. 1.1. Графические изображения для обозначения сущностей

    Связь (relationship) определяется как отношение или некоторая ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения типа "отец-сын" или производственные отношения типа "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи (рис. 1.2).

    Рис. 1.2. Графические изображения для обозначения связей

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

    Рис. 1.3. Диаграмма "сущность-связь" для
    примера сотрудников некоторой компании

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

    Рис. 1.4. Диаграмма "сущность-связь" для примера
    сотрудников, участвующих в работе над проектами

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

    Рис. 1.5. Диаграмма "сущность-связь" для общего примера компании

    Примечание
    На указанных диаграммах могут быть отражены более сложные зависимости между отдельными сущностями, которые отражают обязательность выполнения некоторых дополнительных условий, определяемых спецификой решаемой задачи и моделируемой предметной области. В частности, могут быть отражены связи подчинения одной сущности другой или введения ограничений на действие отдельных связей. В подобных случаях используются дополнительные графические обозначения, отражающие особенности соответствующей семантики (рис. 1.1, 1.2).
     Ограниченность ERD проявляется при конкретизации концептуальной модели в более детальное представление моделируемой программной системы, которое кроме статических связей должно содержать информацию о поведении или функционировании отдельных ее компонентов. Для этих целей в рамках ССА используется другой тип диаграмм, получивших название диаграмм потоков данных. А сейчас перейдем к диаграммам SADT.

    Диаграммы функционального моделирования

    Начало разработки диаграмм функционального моделирования относится к середине 1960-х годов, когда Дуглас Т. Росс предложил специальную технику моделирования, получившую название SADT (Structured Analysis & Design Technique). Военно-воздушные силы США использовали методику SADT в качестве части своей программы интеграции компьютерных и промышленных технологий (Integrated Computer Aided Manufacturing, ICAM) и назвали ее IDEFO (Icam DEFinition). Целью программы ICAM было увеличение эффективности компьютерных технологий в сфере проектирования новых средств вооружений и ведения боевых действий. Одним из результатов этих исследований являлся вывод о том, что описательные языки не эффективны для документирования и моделирования процессов функционирования сложных систем. Подобные описания на естественном языке не обеспечивают требуемого уровня непротиворечивости и полноты, имеющих доминирующее значение при решении задач моделирования.
    В рамках программы ICAM было разработано несколько графических языков моделирования, которые получили следующие названия:
    • Нотация IDEF0 - для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем.
    • Нотация IDEF1 - для документирования информации о производственном окружении систем.
    • Нотация IDEF2 - для документирования поведения системы во времени.
    • Нотация IDEF3 - специально для моделирования бизнес-процессов.
    Нотация IDEF2 никогда не была полностью реализована. Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X. Методология IDEF-SADT, нашла применение в правительственных и коммерческих организациях, поскольку на тот период времени вполне удовлетворяла различным требованиям, предъявляемым к моделированию широкого класса систем.

    В начале 1990 года специально образованная группа пользователей IDEF (IDEF Users Group), в сотрудничестве с Национальным институтом по стандартизации и технологии США (National Institutes for Standards and Technology, NIST), предприняла попытку создания стандарта для IDEFO и IDEF1X. Эта попытка оказалась успешной и завершилась принятием в 1993 году стандарта правительства США, известного как FIPS для данных двух технологий IDEFO и IDEF1X. В течение последующих лет этот стандарт продолжал активно развиваться и послужил основой для реализации в некоторых первых CASE-средствах.

    Методология IDEF-SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели сиетемы какой-либо предметной области. Функциональная модель SADT отображает структуру процессов функционирования системы и ее отдельных подсистем, т. е. выполняемые ими действия и связи между этими действиями. Для этой цели строятся специальные модели, которые позволяют в наглядной форме представить последовательность определенных действий. Исходными строительными блоками любой модели IDEFO процесса являются деятельность (activity) и стрелки (arrows).

    Рассмотрим кратко эти основные понятия методологии IDEF-SADT, которые используются при построении диаграмм функционального моделирования. Деятельность представляет собой некоторое действие или набор действий, которые имеют фиксированную цель и приводят к некоторому конечному результату. Иногда деятельность называют просто процессом. Модели IDEFO отслеживают различные виды деятельности системы, их описание и взаимодействие с другими процессами. На диаграммах деятельность или процесс изображается прямоугольником, который называется блоком. Стрелка служит для обозначения некоторого носителя или воздействия, которые обеспечивают перенос данных или объектов от одной деятельности к другой. Стрелки также необходимы для описания того, что именно производит деятельность и какие ресурсы она потребляет. Это так называемые роли стрелок - ICOM - сокращение первых букв от названий соответствующих стрелок IDEFO. При этом различают стрелки четырех видов:
    • I (Input) - вход, т. е. все, что поступает в процесс или потребляется процессом.
    • С (Control) - управление или ограничения на выполнение операций процесса.
    • О (Output) - выход или результат процесса.
    • М (Mechanism) - механизм, который используется для выполнения процесса.
    Методология IDEFO однозначно определяет, каким образом изображаются на диаграммах стрелки каждого вида ICOM. Стрелка Вход (Input) выходит из левой стороны рамки рабочего поля и входит слева в прямоугольник процесса. Стрелка Управление (Control) входит и выходит сверху. Стрелка Выход (Output) выходит из правой стороны процесса и входит в правую сторону рамки. Стрелка Механизм (Mechanism) входит в прямоугольник процесса снизу. Таким образом, базовое представление процесса на диаграммах IDEFO имеет следующий вид (рис. 1.6).
    Техника построения диаграмм представляет собой главную особенность методологии IDEF-SADT. Место соединения стрелки с блоком определяет тип интерфейса. При этом все функции моделируемой системы и интерфейсы на диаграммах представляются в виде соответствующих блоков процессов и стрелок ICOM. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, изображается с левой стороны блока. Результаты процесса представляются как выходы процесса и показываются с правой стороны блока. В качестве механизма может выступать человек или автоматизированная система, которые реализуют данную операцию. Соответствующий механизм на диаграмме представляется стрелкой, которая входит в блок процесса снизу.

    Рис. 1.6. Обозначение процесса и стрелок ICOM на диаграммах IDEF0

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

    Рис. 1.7. Пример исходной диаграммы IDEF-SADT для
    процесса оформления кредита в банке

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

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

    IDEF3

    IDEF3 -модель потоков данных описывающая взаимоотношения между процессами обработки информации. Описывает последовательность выполнения процессов и временное взаимодействие объектов. ДОполняет диаграмму IDEF0.
    Элементы IDEF3:
    • Единица работы. Где Process Name - имя работы, а A0 - идентификатор работы.
    • Линии
      • Основная. Связывает единицы работ между собой.
      • Линия отношения. Связывает единицы работ с внешними объектами, невходящими в модель.
      • Потоков объектов. Описывает использование объекта в нескольких единицах работ. Объект появляется в одной, используется в другой.
    • Перекрестки

      • |&

        Асинхронное и

      • |&|

        Синхронное и

      • |o

        Асинхронное или

      • |o|

        Синхронное или

      • |x

        Исключающие или(XOR)

    Рис. Пример IDEF0 диаграммы

    Рис. Пример IDEF3 диаграммы

    Диаграммы потоков данных.

    Основой данной методологии графического моделирования информационных систем является специальная технология построения диаграмм потоков данных DFD. В разработке методологии DFD приняли участие многие аналитики, среди которых следует отметить Э. Йордона (Е. Yourdon). Он является автором одной из первых графических нотаций DFD . В настоящее время наиболее распространенной является так называемая нотация Гейна-Сарсона (Gene-Sarson), основные элементы которой будут рассмотрены в этом разделе.

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

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

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

    Рис. 1.8. Изображение внешней сущности на диаграмме потоков данных

    Процесс представляет собой совокупность операций по преобразованию входных потоков данных в выходные в соответствии с определенным алгоритмом или правилом. Хотя физически процесс может быть реализован различными способами, наиболее часто подразумевается программная реализация процесса. Процесс на диаграмме потоков данных изображается прямоугольником с закругленными вершинами (рис. 1.9), разделенным на три секции или поля горизонтальными линиями. Поле номера процесса служит для идентификации последнего. В среднем поле указывается имя процесса. В качестве имени рекомендовано использовать глагол в неопределенной форме с необходимыми дополнениями. Нижнее поле содержит указание на способ физической реализации процесса.

    Рис. 1.9. Изображение процесса на диаграмме потоков данных

    Рис. 1.10. Изображение подсистемы на диаграмме потоков данных

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

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

    Рис. 1.11. Изображение накопителя на диаграмме потоков данных

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

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

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

    Рис. 1.12. Пример диаграммы DFD для процесса получения
    некоторой суммы наличными по кредитной карточке


Разработка программных систем

Содержание

  • Введение
  • Visio
  • Общие вопросы разработки
  • Структурное проектирование
  • Unified Process
  • Глоссарий
  • Список литературы
  • Книги

    • Visio

    Не секрет, что хороший специализированный инструмент на порядок более эффективен в своей области применения, чем очень продвинутый, но универсальный. Это нехитрое правило распространяется практически на все сферы человеческой деятельности, не исключая деловую графику. Какими бы мощными и гибкими ни были Corel Draw или AutoCAD, при отображении тонкостей субординации между старшими менеджерами и младшими супервайзерами богатство возможностей этих продуктов пользователю, скорее, в тягость. С другой стороны, обычные графические средства офисных пакетов зачастую ставят продвинутого пользователя в положение скульптора, которого для работы снабдили конструктором Lego. Интересный результат, безусловно, можно получить и в этом случае, но вряд ли он будет соизмерим с затраченными усилиями.

    К счастью, существует золотая середина - инструмент, благодаря которому "чайник" может за считанные минуты соорудить пристойную диаграмму, а профессионал - быстро и качественно творить чудеса в промышленных масштабах. Этот инструмент называется Microsoft Visio. Несмотря на то, что пакет Visio развивается с 1990 года, претенциозную приставку в названии он приобрел достаточно недавно - в 2000 году. Приняв Visio в семейство своих продуктов, Microsoft приложил значительные усилия по его интеграции с Office.

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

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

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

    3. Схемы и чертежи. Сюда относятся электротехнические схемы, разного рода планы (офисов, квартир, местности) и все, чем нас мучили на черчении (епархия AutoCAD и прочих двумерных CAD'ов).

    На первый взгляд, Visio больше всего похож на несложный векторный редактор. Такая простота легко объяснима - нестандартные дизайнерские изыски в данном случае неуместны. Человеку, привыкшему к удобным и мощным средствам Corel Draw или Adobe Illustrator, в тесных рамках инструментария Visio придется тяжело - мучительно не хватает кривых Безье и нормальных средств работы с контрольными точками. Единственным спасением для дизайнера, который хочет изобразить нечто оригинальное, являются операции над фигурами (объединение, вычитание, пересечение и т.д.), которые позволяют создавать закрашенные объекты с произвольным контуром. Но, в любом случае, рисование в Visio сколько-нибудь сложных форм - занятие не для слабонервных.

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

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

    Visio позволяет делать шейпы умными (smart shapes). Использовав "главный калибр" Visio - управляющее окно шейпа (shape sheet), пользователь получает доступ ко всем параметрам шейпа : размерам и положению на листе, видимости, цвету заливки, форматированию текста, реакции на щелчки мыши - всего не перечислить.

    Применяя встроенные формулы, можно привязывать одни параметры шейпа к другим, а также ставить их в зависимость от внешних данных и событий. Существует также возможность ссылаться на самостоятельно созданные дополнительные переменные для хранения свойств (custom properties ) шейпа . Запрограммированный таким образом умный шейп вполне оправдывает свое название, меняя вид в зависимости от окружения.

    Для того чтобы "пощупать" возможности Visio по созданию смарт-шейпов , поставляю учебно-шуточная задачу изображения отношений между работниками абстрактного офиса. Шейпы , обозначающие работников, должны, основываясь на внутренних переменных, выражать свое отношение к зарплате, боссу и подчиненным. Работники, довольные зарплатой, улыбаются, недовольные - грустят, начальство хмурит брови.

    И вот что из этого получилось.

    Еще одной сильной стороной Visio являются мощные средства для работы с внешними программами и базами данных. Аналогично другим продуктам Microsoft , автоматизация Visio осуществляется через содержащиеся в нем COM-объекты, которые могут задействоваться с помощью любого COM-контроллера: Visual C++, C#, Delphi , VBA.

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

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

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

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

    Разумеется, все это разнообразие изрядно стоит. Существует несколько комплектаций Visio , различающихся полнотой наборов мастер-шейпов и расширений. Минимальную комплектацию ( Standard ) отдадут в хорошие руки примерно за 300 у .е ., а максимальную ( Enterprise Edition ) - за 1000 (ах, простите, 999) у.е .

    Однако стандартные наборы - не единственный источник нужных мастер-шейпов . Несметное их количество создано руками пользователей и доступно в Интернете.

    Поскольку возможности Visio достаточно широки, для его эффективного использования необходима серьезная документация. К сожалению, система помощи в Microsoft Visio 2002 Professional , послужившей объектом для опытов при написании обзора, оказалась достаточно поверхностной . Однако это не стало неразрешимой проблемой, поскольку в Интернете обнаружилось достаточно много информации о Visio . Больше всех порадовал сайт visio.artberg.ru , содержащий большое количество русскоязычных материалов (в том числе - доступный к скачиванию учебник в pdf-формате), а также созданные отечественными поклонниками Visio наборы мастер-шейпов с "национальной" спецификой (например, ГОСТовские обозначения радиодеталей).

    Несмотря на необъятное поле возможных применений, Visio все же является узкоспециализированным графическим инструментом - портрет любимой или пейзаж Простоквашино в дождливый день с его помощью рисовать вряд ли надо. Также не стоит использовать его для полномасштабного инженерного проектирования механических деталей или зданий. Главным преимуществом Visio является возможность, один раз настроив зависимость формы от содержания, более к изобразительным вопросам не возвращаться, концентрируясь исключительно на смысле. Возможно, только седой ветеран работы с Corel Draw или инструментами рисования Microsoft Office способен в полной мере оценить, сколько при этом будет сэкономлено времени и нервов.

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

    Десять аргументов в пользу применения Visio 2003

    1. Документирование и анализ бизнес-процессов.

    Проектирование, документирование и анализ бизнес-процессов с помощью шаблонов и фигур, поддерживающих проекты по управлению бизнес-процессами (BPM), включая программы повышения качества Six Sigma и документацию ISO 9000.

    2. Отслеживание комментариев, добавляемых пользователями.

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

    3. Совместная работа.

    Совместная работа с диаграммами при помощи служб Windows SharePoint Services .

    4. Более естественный способ добавления комментариев к диаграммам на планшетных компьютерах.

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

    5. Средства для проведения совместных обсуждений.

    Новые шаблоны Visio 2003 позволяют записывать и структурировать идеи в ходе совместных обсуждений. Можно экспортировать диаграммы совместных обсуждений в Microsoft Word , Microsoft Excel или XML для быстрого создания других бизнес-файлов .

    6. Создание календарей на основе данных Outlook .

    Можно преобразовывать календари Microsoft Outlook - в календари Visio , обеспечивающие широкие возможности форматирования и совместного использования.

    7. Упрощенное создание технических диаграмм.

    Воспользуйтесь многочисленными усовершенствованиями в средствах построения диаграмм баз данных, программного обеспечения, а также сетевых, инженерных и веб-диаграмм в Visio 2003.

    8. Быстрое создание и изменение диаграмм.

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

    9. Создание мощных интегрированных решений.

    Возможность интеграции Visio 2003 с решениями, использующими веб-службы XML и программное обеспечение Microsoft .NET ў для объединения людей, информации, систем и устройств. Возможность подключения диаграмм к важным деловым данным для улучшенного восприятия данных и быстрого принятия решений.

    10. Доступ к улучшенным средствам поддержки для других регионов и языков.

    Доступны две новые языковые версии Visio 2003 ў на польском и чешском языках. Общее число поддерживаемых языков достигло 17; также реализована улучшенная поддержка восточно-азиатского и двунаправленного письма.

    Дополнительные аргументы в пользу обновления

    При обновлении до уровня Visio 2003 пользователи Microsoft Visio 2000 и Visio 5.0 получают следующие преимущества:

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

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

    • Более эффективное развертывание и сопровождение Visio . Установщик Microsoft Windows - оптимизирует процесс развертывания и поддержки Visio в масштабах предприятия. Visio Professional 2003 обнаруживает и восстанавливает потерянные или поврежденные файлы, необходимые для работы, помогая сохранить работу в случае сбоя программы.


Инструмент: Вспомогательный

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

Инструмент: Редактирования

Набор инструментов Visio, доступных только в режиме редактирования и предназначенных для изменения формата или формы существующих фигур, а также для создания новых фигур.
Инструменты редактирования представлены на панели инструментов Standard в группе, которая начинается инструментом Pointer Tool и заканчивается инструментом Rotation Tool.

Интерфейс

Интерфейс - это множество операций, которые используются для определения услуг класса или компонента.
Интерфейс служит для именования такого множества операций, а также для определения их сигнатур и результирующих действий. Главное внимание при этом уделяется не структуре данной услуги, а именно ее результирующему действию. Интерфейс не предлагает реализацию своих операций, в список которых можно также включать сигналы, которые будут обрабатываться классом.
Интерфейс используется для определения услуги, которую один элемент поставляет, а другие могут затребовать. Он предоставляет имя множеству операций, которые имеют осуществляют некоторое интересное, с логической тонки зрения, поведение системы или ее части. Интерфейс служит для определения услуги, которую предлагает класс или компонент и которою он реализует. Таким образом, интерфейс охватывает логические и физические границы системы. Логическую реализацию интерфейса может осуществлять как один класс, так и несколько различных классов (которые, скорее всего, будут частью подсистемы какого-то компонента). При этом один или несколько компонентов могут входить в физический пакет, соответствующий интерфейсу.
Если интерфейс реализуется (в программном коде) с помощью класса, то этот класс должен объявить или унаследовать все операции интерфейса. Кроме этого, у него также могут иметься дополнительные операции (см. realization). Если же класс реализует не один, а несколько интерфейсов, то и в этом случае он должен иметь все операции, представленные в этих интерфейсах. Одна и та же операция может появляться в различных интерфейсах. Если их сигнатуры совпадают, то они либо представляют собой одну и ту же операцию, либо создают конфликтную ситуацию, и тогда модель считается плохо согласованной. (При реализации могут применяться дополнительные правила для сопоставляемых сигнатур. Например, в языке C++ игнорируются имена параметров и возвращаемых значений.) В интерфейсе нет никаких указаний относительно атрибутов или ассоциаций класса, так как они являются частью его реализации.
Интерфейс - это обобщаемый элемент. Интерфейс-прямой потомок наследует все операции своего прямого предка и может добавлять к ним новые. Реализацию можно рассматривать как наследование поведения; класс наследует операции другого классификатора, но не его структуру. Класс может реализовывать другой класс. Класс, служащий для спецификации, ведет себя при этом как интерфейс, так как только его операции затрагивают отношение.
Интерфейс может принимать участие в ассоциациях. Однако у него не может быть ассоциации, которая допускала бы навигацию от интерфейса. Интерфейс может участвовать в ассоциации только в том случае, если ассоциация допускает навигацию только, но направлению к интерфейсу. Нотация


кодирование

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


линейка(ruler)

Линейки - это элементы интерфейса, которые располагаются слева и вверху окна редактирования и предназначены для определения размеров и расстояний между фигурами. Главный параметр линейки - шкала делений, которая зависит от используемого в текущий момент масштаба изображения и единиц размерности рисунка.
Чтобы скрыть линейки, выберите команду View > Rulers. Для отображения скрытых линеек необходимо повторно выполнить эту команду.

лист(page)

Рабочий лист является основной средой разработки изображений в Visio. Число листов в документе не ограничено.
Каждый рабочий лист определяется набором основных свойств: именем, размерами, ориентацией, используемыми единицами измерения, фоном и т. д. Эти параметры могут быть определены как при создании нового рабочего листа, так и в процессе работы. Для изменения параметров листа выберите команду File > Page Setup и перейдите на вкладку Page Setup.
Для идентификации листа в документе его имя указывается на ярлычке, располагающемся в левом нижнем углу окна редактирования. Контекстное меню этого ярлычка содержит основные команды управления листом: удаление, перемещение, добавление нового и т. д.
По умолчанию каждый новый лист имеет размеры, соответствующие печатному формату А4: 210x297 мм. Однако возможный размер листа ничем не ограничен. Размер листа устанавливается в окне Page Setup на вкладке Page Size. До тех пор, пока размер листа совпадает с печатным размером одной страницы, понятия лист и страница идентичны.


Маркер: Вершины(vertices)

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

Маркер: Выделения (selection handle)

Маркер, предназначенный для изменения геометрических размеров фигуры. Каждая дву- или трехмерная фигура имеет восемь маркеров выделения: четыре из них расположены в вершинах, а еще четыре - в серединах сторон описывающего фигуру прямоугольника. У одномерных фигур маркеров выделения нет - их заменяют конечные маркеры.

Маркер: Конечный (endpoint)

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

Маркер: Управления (control handle)

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

Мастер (master)

Термин мастер имеет двойное значение.
* Фигура, представленная в трафарете и имеющая на страиваемые параметры, которые определяются при переносе фигуры из трафарета на лист.
* Надстройка Visio, позволяющая автоматически выпол нять настройку определенных параметров. Примером такой надстройки может служить мастер изменения цветовой схемы Color Scheme.

Масштаб (scale)

Мера соотношения между действительным расстоянием и расстоянием, представленным на рисунке. Например, план помещений здания может иметь масштаб одного метра реальной длины к одному сантиметру на рисунке.
Установка параметров масштаба и их соотношений выполняется в окне диалога Page Setup на вкладке Drawing Scale.


окно редактирования

Элемент интерфейса Visio, в котором отображается рабочий лист. По умолчанию окно редактирования обрамляют линейки.


Панель инструментов(toolbar)

Элемент интерфейса Visio, который объединяет различные кнопки, позволяющие получить быстрый доступ к скрытым командам или командам меню.' В Visio имеется двенадцать панелей инструментов в режиме редактирования и две панели инструментов в режиме электронной таблицы.
По умолчанию в Visio открыты только панели инструментов Standard и Format. Чтобы открыть другие панели инструментов, выберите команду View > Toolbars и в открывшемся меню выберите необходимую панель. Чтобы скрыть открытую ранее панель, необходимо повторить эту процедуру.
При необходимости вы можете создавать пользовательские панели инструментов.

Привязка(guide, guide point)

Вспомогательный инструмент, используемый для точного позиционирования фигур и других объектов на листе Visio. В качестве привязки могут быть использованы линии привязки (guide) и точки привязки (guide point).
* Точка привязки позволяет выполнить привязку точки соединения к определенному узлу сетки листа.
* Линия привязки позволяет выполнить привязку одной или нескольких точек соединения, лежащих на одной прямой, к произвольной прямой.

Проводник Visio(shape explorer)

Дополнительный инструмент, позволяющий выполнить поиск:
* места нахождения мастера фигуры, если не известно в каком трафарете он находится;
* папки, в которой находится искомый трафарет;
* категории, в которой содержится шаблон, необходи мый для создания специфического документа,
* места нахождения мастера Visio, необходимого для вы полнения специфических задач.
Результатом поиска будет список, используя пункты которого можно вставить найденную фигуру на лист, открыть трафарет, загрузить шаблон или мастер. Чтобы открыть инструмент Shape explorer, выберите команду Toots > Macros > Shape explorer.

Проектирование

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

Предметная область

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


Рисунок:Тип(drawing type)

Для упрощения разработки и создания документов определенной направленности в Visio имеется большая подборка стандартных типов рисунков. Каждый тип основан на стандартном шаблоне, устанавливаемом по умолчанию, и содержит наиболее необходимые трафареты, в которых содержатся мастера, позволяющие создавать типичные для решаемой задачи фигуры.
Все доступные типы представлены в окне диалога Choose Drawing Type, которое открывается после выбора команды File > Choose Drawing Type. Типы разделены по категориям, например в категории Map представлено два типа: Directional Map (географическая схема) и Geographic maps (географические карты).


системный анализ

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

сопровождение

эксплуатация систем и внесение в нее изменений в процессе эксплуатации с целью:
- исправления онаруженных ошибок;
- адаптация к изменениям условия эксплуатации;
- усовершенствования отдельных характеристик

стратегии разработки П.О.

1. Водопадная-линейная последовательность этапов. Каждый этап проходит один раз.
2. Инкрементная- основана на пошаговом учете заранее сформулированных требований.
3. Эволюционная- основана на последовательности шагов реализации с учетом изменения и уточнения требований.

Свойства: Настраиваемые(custom property)

Специальные свойства, определяющие параметры фигуры, создаваемой с помощью мастера. Эти свойства определяются в окне диалога Custom Property, которое открывается после выбора команды Shape > Custom Property.
Установленные по умолчанию свойства можно изменять или, если это необходимо, добавлять новые свойства. Это выполняется в окне диалога Define Custom Property. Примером использования Настраиваемых свойств может являться задание числа столбцов в плоской гистограмме.

Связывание(link)

Инструмент, позволяющий создать в документе Visio ссылку на фрагмент другого приложения. В отличие от внедренного фрагмента, связывание всегда осуществляется с уже существующим, то есть созданным ранее, документом. Связывание может быть выполнено только для тех документов, приложения которых поддерживают технологию OLE 2.
Для создания связанного объекта откройте документ, фрагмент которого необходимо связать, и скопируйте его в буфер обмена. Перейдите к тому листу Visio, на который необходимо вставить связанный объект, и выберите команду Edit > Paste Special. В открывшемся окне диалога установите переключатель в положение Paste link и в списке выберите формат, в котором необходимо вставить фрагмент. Нажмите кнопку ОК.
Для изменения связанного объекта, выделите его и выберите команду Edit > Link Object > Edit. При редактировании связанного объекта всегда открывается его "родное" приложение.

Сетка(grid)

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

Синхронная копия(synchronized copy)

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

Склеивание(glue)

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

Слой(layer)

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

Соединитель(connector)

Фигура, предназначенная для соединения двух объектов на рабочем листе. Соединение может выполняться тремя способами: точка к точке (point-to-point), фигура к фигуре (shape-to-shape) и смешанным образом (shape-to-point). Соединители, как правило, являются одномерными фигурами.
Все стандартные соединители, устанавливаемые по умолчанию, находятся в трафарете Connectors. Однако некоторые из них могут содержаться и в других трафаретах.

Соединитель: От точки к точке(point-to-point)

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

Соединитель: От фигуры к фигуре(shape-to-shape)

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

Стиль(style)

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

Страница(page)

Печатная площадь рабочего листа. Один рабочий лист может содержать несколько печатных страниц. По умолчанию каждый новый рабочий лист имеет размеры печатной страницы формата А4.
Печатная площадь является настраиваемым параметром. Она принимает дискретные значения, определяемые стандартными печатными форматами. Для изменения печат ного формата страницы выберите команду File > Page Set up, перейдите на вкладку Print Setup и в раскрывающему списке Paper Size выберите необходимый размер.


Тестирование

выявление ошибок и дефектов в логике, функциях и форме реализации системы

Текстовый блок(text block)

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

Точка соединения(connection point)

Специальный инструмент Visio, позволяющий соединять различные объекты на листе. Очень часто точка соединения используется для "привязки" разных фигур друг к другу. Точка соединения может быть внутренняя, внешняя и смешанная, располагающаяся на контуре фигуры.
Синий крестик, обозначающий точку соединения, является непечатаемым объектом и может быть скрыт. Чтобы скрыть точки соединения, выберите команду View > Connection points.

Точки данных(data points)

Маркеры управления, предназначенные для изменения значений величин отображения на графике или диаграмме.

Трафарет(stencil)

Файл Visio, имеющий расширение .vss и содержащий специальную панель, на которой находятся мастера и фигуры, используемые как основа при создании пользовательских изображений. По умолчанию трафареты появляются в левой части окна Visio в собственном окне Stencil window. Все трафареты, устанавливаемые по умолчанию, содержатся в папке Solutions и разделены на категории. Чтобы в процессе работы над документом открыть необходимый трафарет, выберите команду File > Stencils, в открывшемся меню выберите необходимую категорию, а в ней - нужный трафарет.
На панели инструментов Standard имеется кнопка со списком Open Stencil, которая также содержит все зарегистрированные категории с трафаретами. Шаблоны содержат предустановленный набор трафаретов, которые наиболее необходимы при разработке данного типа документов.


Узел сетки

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


Фигура(shape)

Термин фигура имеет тройное значение. * Открытый или закрытый объект, созданный с использованием инструментов или команд Visio. * Сгруппированный или объединенный набор фигур. * Объект, созданный в результате перемещения мастера из трафарета на рабочий лист.

Фигура: Выбранная(selection shape)

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

Фигура: Гиперссылка на страницу(off-page reference)

Специальная фигура Off-page reference, представленная в шаблонах Audit Diagram, Basic Flowchart, SDL Diagram, TQM Diagram и Work Flow Diagram, которая позволяет выполнить автоматическое перемещение к существующему листу в документе.

Фон(background)

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

Формат(format)

Видимые параметры фигуры, такие, как толщина и цвет ее линий, цвет или узор заливки, шрифт и т.д. Формат может быть изменен как у отдельного элемента, так и у всей фигуры сразу. Последнее выполняется с помощью изменения стиля фигуры.
Команды изменения формата представлены в меню Format и на панелях инструментов Standard, Format, Format Text и Format Shapes.


Цветовая схема(color scheme)

Набор цветов, закрепленных за определенными элементами рисунка: фигурами, текстом, соединителями и т.д. В Visio 2000 имеется набор стандартных цветовых схем и инструмент, предназначенный для создания пользовательской схемы. Чтобы изменить цветовую схему фигуры, выберите команду Tools > Macros > Visio Extras > ColorSchemes.


Шаблон(template)

Файл Visio, имеющий расширение .vst, содержащий заготовку документа определенной направленности. Шаблон может содержать необходимые трафареты, панели инструментов, стили и т.д., облегчающие создание определенного типа рисунка.
В visio содержится набор шаблонов, устанавливаемых по умолчанию при инсталяции. чтобы загрузить новый шаблон, выберите команду File > New > ChoosedrawingPage, выберите необходимую категорию, а в ней - шаблон. При необходимости вы можете создавать пользовательские шаблоны.
При открытии шаблона всегда создается новый документ.


Введение

На главную страницу

Лекция 1: Введение

  1. Основные понятия и определения
  2. Область применения
  3. Краткий исторический обзор развития работ в области ИИ
  4. Функциональная структура использования СИИ
  5. Литература

Основные понятия и определения.

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

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

Область применения.

  • Доказательства теорем;
  • Игры;
  • Распознавание образов;
  • Принятие решений;
  • Адаптивное программирование;
  • Сочинение машинной музыки;
  • Обработка данных на естественном языке;
  • Обучающиеся сети (нейросети);
  • Вербальные концептуальные обучения.

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

Краткий исторический обзор развития работ в области ИИ.

Начало исследований в области ИИ (конец 50-х годов) связывают с работами Ньюэлла, Саймана и Шоу, исследовавших процессы решения различных задач. Результатами их работ явились такие программы как "ЛОГИК-ТЕОРЕТИК", предназначенная для доказательства теорем в исчислении высказываний, и "ОБЩИЙ РЕШАТЕЛЬ ЗАДАЧ". Эти работы положили начало первому этапу исследований в области ИИ, связанному с разработкой программ, решающих задачи на основе применения разнообразных эвристических методов.

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

На дальнейшие исследования в области ИИ большое влияние оказало появление метода резолюций Робинсона, основанного на доказательстве теорем в логике предикатов и являющегося исчерпывающим методом доказательства. При этом определение термина ИИ претерпело существенное изменение. Целью исследований, проводимых в направлении ИИ, стала разработка программ, способных решать "человеческие задачи". Так, один из видных исследователей ИИ того времени Р. Бенерджи в 1969 году писал: "Область исследований, обычно называемую ИИ, вероятно, можно представить как совокупность методов и средств анализа и конструирования машин, способных выполнять задания, с которыми до недавнего времени мог справиться только человек. При этом по скорости и эффективности машины должны быть сравнимы с человеком." Функциональный подход к направленности исследований по ИИ сохранился в основном до настоящего времени, хотя еще и сейчас ряд ученых, особенно психологов, пытаются оценивать результаты работ по ИИ с позиций их соответствия человеческому мышлению.

Исследовательским полигоном для развития методов ИИ на первом этапе явились всевозможные игры, головоломки, математические задачи. Некоторые из этих задач стали классическими в литературе по ИИ (задачи об обезьяне и бананах, миссионерах и людоедах, Ханойской башне игра в 15 и другие). Выбор таких задач обуславливался простотой и ясностью проблемной среды (среды, в которой разворачивается решение задачи), ее относительно малой громоздкостью, возможностью достаточно легкого подбора и даже искусственного конструирования "под метод". Основной расцвет такого рода исследований приходится на конец 60-х годов, после чего стали делаться первые попытки применения разработанных методов для задач, решаемых не в искусственных, а в реальных проблемных средах. Необходимость исследования систем ИИ при их функционировании в реальном мире привело к постановке задачи создания интегральных роботов. Проведение таких работ можно считать вторым этапом исследований по ИИ. В Стэнфордском университете, Стэнфордском исследовательском институте и некоторых других местах были разработаны экспериментальные роботы, функционирующие в лабораторных условиях. Проведение этих экспериментов показало необходимость решения кардинальных вопросов, связанных с проблемой представления знаний о среде функционирования, и одновременно недостаточную исследованность таких проблем, как зрительное восприятие, построение сложных планов поведения в динамических средах, общение с роботами на естественном языке. Эти проблемы были более ясно сформулированы и поставлены перед исследователями в середине 70-х гг, связанных с началом третьего этапа исследований систем ИИ. Его характерной чертой явилось смещение центра внимания исследователей с создания автономно функционирующих систем, самостоятельно решающих в реальной среде поставленные перед ними задачи, к созданию человеко-машинных систем, интегрирующих в единое целое интеллект человека и способности ВМ для достижения общей цели - решение задачи, поставленной перед интегральной человеко-машинной решающей системой. Такое смещение обуславливалось двумя причинами:

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

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

Функциональная структура использования СИИ.

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

Литература

  1. Перспективы развития вычислительной техники.Кн.2. Интеллектуализация ЭВМ.М., 1989
  2. Уинстон П. Искусственный интеллект. М.1980.
  3. Хант Э. Искусственный интеллект. М.1978.


Модели и методы решения задач

На главную страницу

Лекции 2-3: Модели и методы решения задач

  1. Классификация представления задач.
    • Логические модели.
    • Сетевые модели
    • Продукционные модели.
    • Сценарии.
  2. Интеллектуальный интерфейс
    • Классификация уровней понимания
  3. Методы решения задач.
    • Решение задач методом поиска в пространстве состояний.
    • Решение задач методом редукции.
    • Решение задач дедуктивного выбора
    • Решение задач, использующие немонотонные логики, вероятностные логики.

Классификация представления задач.

Логические модели.

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

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

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

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

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

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

Сетевые модели

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

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

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

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

Продукционные модели.

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

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

(i); Q; Р; А=>В; N.

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

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

Основным элементом продукции является ее ядро: А=>В. Интерпретация ядра продукции может быть различной и зависит от того, что стоит слева и справа от знака секвенции =>. Обычное прочтение ядра продукции выглядит так: ЕСЛИ A, ТО B, более сложные конструкции ядра допускают в правой части альтернативный выбор, например, ЕСЛИ А, ТО B1, ИНАЧЕ B2. Секвенция может истолковываться в обычном логическом смысле как знак логического следования В из истинного А (если А не является истинным выражением, то о В ничего сказать нельзя). Возможны и другие интерпретации ядра продукции, например A описывает некоторое условие, необходимое для того, чтобы можно было совершить действие В.

Элемент Р есть условие применимости ядра продукции. Обычно Р представляет собой логическое выражение (как правило, предикат). Когда Р принимает значение "истина", ядро продукции активизируется. Если Р ложно, то ядро продукции не может быть использовано. Например, если в продукции "НАЛИЧИЕ ДЕНЕГ; ЕСЛИ ХОЧЕШЬ КУПИТЬ ВЕЩЬ X, ТО ЗАПЛАТИ В КАССУ ЕЕ СТОИМОСТЬ И ОТДАЙ ЧЕК ПРОДАВЦУ" условие применимости ядра продукции ложно, т. е. денег нет, то применить ядро продукции невозможно.

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

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

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

Сценарии.

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

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

Интеллектуальный интерфейс

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

Классификация уровней понимания

В существующих ИС можно выделить пять основных уровней понимания и два уровня метапонимания.

Первый уровень характеризуется схемой, показывающей, что любые ответы на вопросы система формирует только на основе прямого содержания, введенного из текста. Если, например, в систему введен текст: "В восемь утра, после завтрака, Петя ушел в школу. В два часа он вернулся домой. После обеда он ушел гулять", то на первом уровне понимания система обязана уметь отвечать правильно на вопросы типа: "Когда Петя ушел в школу?" или "Что сделал Петя после обеда?". В лингвистическом процессоре происходит морфологический, синтаксический и семантический анализ текста и вопросов, относящихся к нему. На выходе лингвистического процессора получается внутреннее представление текста и вопросов, с которыми может работать блок вывода. Используя специальные процедуры, этот блок формирует ответы. Другими словами, уже понимание на первом уровне требует от ИС определенных средств представления данных и вывода на этих данных.

Второй уровень: На втором уровне добавляются средства логического вывода, основанные на информации, содержащейся в тексте. Это разнообразные логики текста (временная, пространственная, каузальная и т. п., которые способны породить информацию, явно отсутствующую в тексте. Для нашего примера на втором уровне возможно формирование правильных ответов на вопросы типа: "Что было раньше: уход Пети в школу или его обед?" или "Гулял Петя после возвращения из школы?" Только построив временную структуру текста, ИС сможет ответить на подобные вопросы.

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

Третий уровень: К средствам второго уровня добавляются правила пополнения текста знаниями системы о среде. Эти знания в ИС, как правило, носят логический характер и фиксируются в виде сценариев или процедур иного типа. На третьем уровне понимания ИС должна дать правильные ответы на вопросы типа: "Где был Петя в десять утра?" или "Откуда Петя вернулся в два часа дня?" Для этого надо знать, что означает процесс "пребывание в школе" и, в частности, что этот процесс является непрерывным и что субъект, участвующий в нем, все время находится "в школе".

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

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

Следующие два уровня понимания реализованы в существующих ИС лишь частично.

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

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

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

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

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

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

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

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

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

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

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

Методы решения задач.

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

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

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

При планировании в пространстве задач ситуация несколько иная. Пространство образуется в результате введения на множестве задач отношения типа: "часть - целое", "задача - подзадача", "общий случай - частный случай" и т. п. Другими словами, пространство задач отражает декомпозицию задач на подзадачи (цели на подцели). PR-проблема состоит в поиске декомпозиции исходной задачи на подзадачи, приводящей к задачам, решение которых системе известно. Например, ИС известно, как вычисляются значения sin x и cos x для любого значения аргумента и как производится операция деления. Если ИС необходимо вычислить tg x, то решением PR-проблемы будет представление этой задачи в виде декомпозиции tgx=sin x/cos x (кроме х=p /2+kp ).

Решение задач методом поиска в пространстве состояний.

Представление задач в пространстве состояний предполагает задание ряда описаний: состояний, множества операторов и их воздействий на переходы между состояниями, целевых состояний. Описания состояний могут представлять собой строки символов, векторы, двухмерные массивы, деревья, списки и т. п. Операторы переводят одно состояние в другое. Иногда они представляются в виде продукций A=>B, означающих, что состояние А преобразуется в состояние В.

Пространство состояний можно представить как граф, вершины которого помечены состояниями, а дуги - операторами.

Таким образом, проблема поиска решения задачи <А,В> при планировании по состояниям представляется как проблема поиска на графе пути из А в В. Обычно графы не задаются, а генерируются по мере надобности.

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

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

Алгоритм кратчайших путей Мура. Исходная вершина X0 помечается числом 0. Пусть в ходе работы алгоритма на текущем шаге получено множество дочерних вершин X(xi) вершины xi. Тогда из него вычеркиваются все ранее полученные вершины, оставшиеся помечаются меткой, увеличенной на единицу по сравнению с меткой вершины xi, и от них проводятся указатели к Xi. Далее на множестве помеченных вершин, еще не фигурирующих в качестве адресов указателей, выбирается вершина с наименьшей меткой и для нее строятся дочерние вершины. Разметка вершин повторяется до тех пор, пока не будет получена целевая вершина.

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

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

Алгоритм Харта, Нильсона и Рафаэля. В алгоритме объединены оба критерия: стоимость пути до вершины g[x) и стоимость пути от вершины h(x) - в аддитивной оценочной функции f{x) =g(x}-h(x). При условии h(x)<hp(x), где hp(x)-действительное расстояние до цели, алгоритм гарантирует нахождение оптимального пути.

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

Решение задач методом редукции.

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

Поиск планирования в пространстве задач заключается в последовательном сведении исходной задачи к все более простым до тех пор, пока не будут получены только элементарные задачи. Частично упорядоченная совокупность таких задач составит решение исходной задачи. Расчленение задачи на альтернативные множества подзадач удобно представлять в виде И/ИЛИ-графа. В таком графе всякая вершина, кроме концевой, имеет либо конъюнктивно связанные дочерние вершины (И-вершина), либо дизъюнктивно связанные (ИЛИ-вершина). В частном случае, при отсутствии И-вершин, имеет место граф пространства состояний. Концевые вершины являются либо заключительными (им соответствуют элементарные задачи), либо тупиковыми. Начальная вершина (корень И/ИЛИ-графа) представляет исходную задачу. Цель поиска на И/ИЛИ-графе-показать, что начальная вершина разрешима. Разрешимыми являются заключительные вершины (И-вершины), у которых разрешимы все дочерние вершины, и ИЛИ-вершины, у которых разрешима хотя бы одна дочерняя вершина. Разрешающий граф состоит из разрешимых вершин и указывает способ разрешимости начальной вершины. Наличие тупиковых вершин приводит к неразрешимым вершинам. Неразрешимыми являются тупиковые вершины, И-вершины, у которых неразрешима хотя бы одна дочерняя вершина, и ИЛИ-вершины, у которых неразрешима каждая дочерняя вершина.

Алгоритм Ченга и Слейгла. Основан на преобразовании произвольного И/ИЛИ-графа в специальный ИЛИ-граф, каждая ИЛИ-ветвь которого имеет И-вершины только в конце. Преобразование использует представление произвольного И/ИЛИ-графа как произвольной формулы логики высказываний с дальнейшим преобразованием этой произвольной формулы в дизъюнктивную нормальную форму. Подобное преобразование позволяет далее использовать алгоритм Харта, Нильсона и Рафаэля.

Метод ключевых операторов. Пусть задана задача <A, B> и известно, что оператор f обязательно должен входить в решение этой задачи. Такой оператор называется ключевым. Пусть для применения f необходимо состояние C, а результат его применения есть I(c). Тогда И-вершина <A,В> порождает три дочерние вершины: <A, C>, <C, f{c)> и <f(c), B>, из которых средняя является элементарной задачей. К задачам <A, С> и <f(c), B> также подбираются ключевые операторы, и указанная процедура редуцирования повторяется до тех пор, пока это возможно. В итоге исходная задача <A, B> разбивается на упорядоченную совокупность подзадач, каждая из которых решается методом планирования в пространстве состояний.

Возможны альтернативы по выбору ключевых операторов, так что в общем случае будет иметь место И/ИЛИ-граф. В большинстве задач удается не выделить ключевой оператор, а только указать множество, его содержащее. В этом случае для задачи <A, B> вычисляется различие между A и B, которому ставится в соответствие оператор, устраняющий это различие. Последний и является ключевым.

Метод планирования общего решателя задач (ОРЗ). ОРЗ явился первой наиболее известной моделью планировщика. Он использовался для решения задач интегрального исчисления, логического вывода, грамматического разбора и др. ОРЗ объединяет два основных принципа поиска:

анализ целей и средств и рекурсивное решение задач. В каждом цикле поиска ОРЗ решает в жесткой последовательности три типа стандартных задач: преобразовать объект А в объект В, уменьшить различие D между А и В, применить оператор f к объекту А. Решение первой задачи определяет различие D второй - подходящий оператор f, третьей - требуемое условие применения С. Если С не отличается от A, то оператор f применяется, иначе С представляется как очередная цель и цикл повторяется, начиная с задачи "преобразовать A в С". В целом стратегия ОРЗ осуществляет обратный поиск-от заданной цели В к требуемому средству ее достижения С, используя редукцию исходной задачи <A, В> к задачам <A, C> и <С, В>.

Заметим, что в ОРЗ молчаливо предполагается независимость различий Друг от друга, откуда следует гарантия, что уменьшение одних различий не приведет к увеличению других.

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

Дедуктивный метод планирования системы QA3, ОРЗ не оправдал возлагавшихся на него надежд в основном из-за неудовлетворительного представления задач. Попытка исправить положение привела к созданию вопросно-ответной системы QA3. Система рассчитана на произвольную предметную область и способна путем логического вывода ответить на вопрос: возможно ли достижение состояния В из A? В качестве метода автоматического вывода используется принцип резолюций. Для направления логического вывода QA3 применяет различные стратегии, в основном синтаксического характера, учитывающие особенности формализма принципа резолюций. Эксплуатация QA3 показала, что вывод в такой системе получается медленным, детальным, что несвойственно рассуждениям человека.

Метод продукций системы STRIPS. В этом методе оператор представляет продукцию Р, А=>В, где Р, А и В - множества ППФ исчисления предикатов первого порядка, Р выражает условия применения ядра продукции А=>В, где В содержит список добавляемых ППФ и список исключаемых ППФ, т. е. постусловия. Метод повторяет метод ОРЗ с тем отличием, что стандартные задачи определения различий и применения подходящих операторов решаются на основе принципа резолюций. Подходящий оператор выбирается так же, как в ОРЗ, на основе принципа "анализ средств и целей". Наличие комбинированного метода планирования позволило ограничить процесс логического вывода описанием состояния мира, а процесс порождения новых таких описаний оставить за эвристикой "от цели к средству ее достижения".

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

Решение задач дедуктивного выбора

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

В соответствии с правилами, установленными в формальной системе, заключительному утверждению-теореме, полученной из начальной системы утверждений (аксиом, посылок), приписывается значение ИСТИНА, если каждой посылке, аксиоме также приписано значение ИСТИНА.

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

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

Метод резолюции используется в качестве полноценного (формального) метода доказательства теорем.

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

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

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

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

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

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

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


Представление знаний в интеллектуальных системах

На главную страницу

Лекция 4: Представление знаний в интеллектуальных системах

  1. Предисловие
  2. Данные и знания. Основные определения.
  3. Особенности знаний. Переход от Базы Данных к Базе Знаний.
  4. Модели представления знаний. Неформальные (семантические) модели.
  5. Формальные модели представления знаний.

Предисловие

В настоящее время в исследованиях по искусственному интеллекту (ИИ) выделились шесть направлений:

  1. Представление знаний.
  2. Манипулирование знаниями.
  3. Общение.
  4. Восприятие.
  5. Обучение.
  6. Поведение.

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

Данные и знания. Основные определения.

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

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

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

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

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

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

Особенности знаний. Переход от Базы Данных к Базе Знаний.

Особенности знаний:

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

    2. Таблица 1.1

    Фамилия | Год рождения | Специальность | Стаж, число лет
Попов | 1965 | Слесарь | 5
Сидоров | 1946 | Токарь | 20
Иванов | 1925 | Токарь | 30
Петров | 1937 | Сантехник | 25

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

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

  2. Структурированность. Информационные единицы должны обладать гибкой структурой. Для них должен выполняться "принцип матрешки", т.е. рекурсивная вложимость одних информационных единиц в другие. Каждая информационная единица может быть включена в состав любой другой, и из каждой информационной единицы можно выделить некоторые составляющие ее информационные единицы. Другими словами, должна существовать возможность произвольного установления между отдельными информационными единицами отношений типа "часть - целое", "род - вид" или "элемент - класс".
  3. Связность. В информационной базе между информационными единицами должна быть предусмотрена возможность установления связей различного типа. Прежде всего эти связи могут характеризовать отношения между информационными единицами. Семантика отношений может носить декларативный или процедурный характер. Например, две или более информационные единицы могут быть связаны отношением "одновременно", две информационные единицы - отношением "причина - следствие" или отношением "быть рядом". Приведенные отношения характеризуют декларативные знания. Если между двумя информационными единицами установлено отношение "аргумент - функция", то оно характеризует процедурное знание, связанное с вычислением определенных функций. Далее будем различать отношения структуризации, функциональные отношения, каузальные отношения и семантические отношения. С помощью первых задаются иерархии информационных единиц, вторые несут процедурную информацию, позволяющую находить (вычислять) одни информационные единицы через другие, третьи задают причинно - следственные связи, четвертые соответствуют всем остальным отношениям.

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

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

  4. Семантическая метрика. На множестве информационных единиц в некоторых случаях полезно задавать отношение, характеризующее ситуационную близость информационных единиц, т.е. силу ассоциативной связи между информационными единицами. Его можно было бы назвать отношением релевантности для информационных единиц. Такое отношение дает возможность выделять в информационной базе некоторые типовые ситуации (например, "покупка", "регулирование движения на перекрестке"). Отношение релевантности при работе с информационными единицами позволяет находить знания, близкие к уже найденным.
  5. Активность. С момента появления ЭВМ и разделения используемых в ней информационных единиц на данные и команды создалась ситуация, при которой данные пассивны, а команды активны. Все процессы, протекающие в ЭВМ, инициируются командами, а данные используются этими командами лишь в случае необходимости. Для ИС эта ситуация не приемлема. Как и у человека, в ИС актуализации тех или иных действий способствуют знания, имеющиеся в системе. Таким образом, выполнение программ в ИС должно инициироваться текущим состоянием информационной базы. Появление в базе фактов или описаний событий, установление связей может стать источником активности системы.

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

Модели представления знаний. Неформальные (семантические) модели.

Существуют два типа методов представления знаний (ПЗ):

  1. Формальные модели ПЗ;
  2. Неформальные (семантические, реляционные) модели ПЗ.

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

Каждому из методов ПЗ соответствует свой способ описания знаний.

1. Логические модели. В основе моделей такого типа лежит формальная система, задаваемая четверкой вида: M = <T, P, A, B>. Множество T есть множество базовых элементов различной природы, например слов из некоторого ограниченного словаря, деталей детского конструктора, входящих в состав некоторого набора и т.п. Важно, что для множества T существует некоторый способ определения принадлежности или непринадлежности произвольного элемента к этому множеству. Процедура такой проверки может быть любой, но за конечное число шагов она должна давать положительный или отрицательный ответ на вопрос, является ли x элементом множества T. Обозначим эту процедуру П(T).

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

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

Множество B есть множество правил вывода. Применяя их к элементам A, можно получать новые синтаксически правильные совокупности, к которым снова можно применять правила из B. Так формируется множество выводимых в данной формальной системе совокупностей. Если имеется процедура П(B), с помощью которой можно определить для любой синтаксически правильной совокупности, является ли она выводимой, то соответствующая формальная система называется разрешимой. Это показывает, что именно правило вывода является наиболее сложной составляющей формальной системы.

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

2. Сетевые модели. В основе моделей этого типа лежит конструкция, названная ранее семантической сетью. Сетевые модели формально можно задать в виде H = <I, C1, C2, ..., Cn, Г>. Здесь I есть множество информационных единиц; C1, C2, ..., Cn - множество типов связей между информационными единицами. Отображение Г задает между информационными единицами, входящими в I, связи из заданного набора типов связей.

В зависимости от типов связей, используемых в модели, различают классифицирующие сети, функциональные сети и сценарии. В классифицирующих сетях используются отношения структуризации. Такие сети позволяют в базах знаний вводить разные иерархические отношения между информационными единицами. Функциональные сети характеризуются наличием функциональных отношений. Их часто называют вычислительными моделями, т.к. они позволяют описывать процедуры "вычислений" одних информационных единиц через другие. В сценариях используются каузальные отношения, а также отношения типов "средство - результат", "орудие - действие" и т.п. Если в сетевой модели допускаются связи различного типа, то ее обычно называют семантической сетью.

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

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

(Имя фрейма:

Имя слота 1(значение слота 1)

Имя слота 2(значение слота 2)

. . . . . . . . . . . . . . . . . . . . . .

Имя слота К (значение слота К)).

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

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

Например, структура табл. 1.1, записанная в виде протофрейма, имеет вид

(Список работников:

Фамилия (значение слота 1);

Год рождения (значение слота 2);

Специальность (значение слота 3);

Стаж (значение слота 4)).

Если в качестве значений слотов использовать данные табл. 1.1, то получится фрейм - экземпляр

(Список работников:

Фамилия (Попов - Сидоров - Иванов - Петров);

Год рождения (1965 - 1946 - 1925 - 1937);

Специальность (слесарь - токарь - токарь - сантехник);

Стаж (5 - 20 - 30 - 25)).

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

Формальные модели представления знаний.

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

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

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

Формальная теория должна, таким образом, удовлетворять следующему определению:

всякая формальная теория F = (A, V, W, R), определяющая некоторую аксиоматическую систему, характеризуется:

наличием алфавита (словаря), A,

множеством синтаксических правил, V,

множеством аксиом, лежащих в основе теории, W,

множеством правил вывода, R.

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

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


Представления знаний в интеллектуальных системах

На главную страницу

Лекция 5: Представление знаний в интеллектуальных системах (часть 2)

  1. Продукционные системы
    • Компоненты продукционных систем
    • Стратегии решений организации поиска
  2. Логический подход. Представление простых фактов в логических системах
    • Примеры применения логики для представления знаний
  3. Литература

Продукционные системы

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

Компоненты продукционных систем

В общем виде под продукцией понимается выражение следующего вида: (i); Q;P;AЮB;N.

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

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

Основным элементом продукции является ее ядро: AЮB. Интерпретация ядра продукции может быть различной и зависит от того, что стоит слева и справа от знака секвенции Ю. Обычное прочтение ядра продукции выглядит так: ЕСЛИ А, ТО В, более сложные конструкции ядра допускают в правой части альтернативный выбор, например , ЕСЛИ А, ТО В1, ИНАЧЕ B2. Секвенция может истолковываться в обычном логическом смысле как знак логического следования В из истинного А (если А не является истинным выражением, то о В ничего сказать нельзя). Возможны и другие интерпретации ядра продукции, например А описывает некоторое условие, необходимое для того, чтобы можно было совершить действие В.

Элемент Р есть условие применимости ядра продукции. Обычно Р представляет собой логическое выражение (как правило предикат). Когда Р принимает значение "истина", ядро продукции активизируется. Если Р "ложно", то ядро продукции не может быть использовано.

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

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

Классификация ядер продукции.

Ядра продукции можно классифицировать по различным основаниям. Прежде всего все ядра делятся на два больших типа: детерминированные и недетерминированные. В детерминированных ядрах при актуализации ядра и при выполнимости А правая часть ядра выполняется обязательно; в недетерминированных ядрах В может выполняться и не выполняться. Таким образом, секвенция Ю в детерминированных ядрах реализуется с необходимостью, а в недетерминированных - с возможностью. Интерпретация ядра в этом случае может, например, выглядеть так: ЕСЛИ А, ТО ВОЗМОЖНО В.

Возможность может определяться некоторыми оценками реализации ядра. Например, если задана вероятность выполнения В при актуализации А, то продукция может быть такой: ЕСЛИ А, ТО С ВЕРОЯТНОСТЬЮ р РЕАЛИЗОВАТЬ В. Оценка реализации ядра может быть лингвистической, связанной с понятием терм-множества лингвистической переменной, например: ЕСЛИ А, ТО С БОЛЬШЕЙ ДОЛЕЙ УВЕРЕННОСТИ В. Возможны иные способы реализации ядра.

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

Особым типом являются прогнозирующие продукции, в которых описываются последствия, ожидаемые при актуализации А, например: ЕСЛИ А, ТО С ВЕРОЯТНОСТЬЮ р МОЖНО ОЖИДАТЬ В.

Дальнейшую классификацию ядер продукции можно провести, опираясь на типовую схему СИИ (рис. 1) Если x и y обозначают любой из блоков рисунка (О,Д,З,Л), то ядро АxЮBy означает, что информация об А берется из блока x, а результат срабатывания продукции В посылает в блок y. Комбинации x и y, осмысленные с точки зрения СИИ, отмечены в табл.1 знаком "+"

Т а б л и ц а 1

Рис 1

Рассмотрим часто встречающийся тип продукции А3ЮВ3. В этом случае А3 и В3 представляют собой некоторые фрагменты информации, хранящейся в базе знаний. При сетевом представлении это могу быть фрагменты семантической сети, при логических моделях - формулы того или иного исчисления. Тогда смысл продукции А3ЮВ3 состоит в замене одного фрагмента базы знаний другим. Для актуализации этой продукции необходимо, чтобы в базе знаний существовал фрагмент, совпадающий с А. При поиске в базе знаний А играет роль образца, а процедура такого писка называется поиском по образцу.

Стратегии решений организации поиска

Для иллюстрации поиска предположим, что в базе знаний для представления знаний используется семантическая сеть (рис.2а) и продукция (рис.2б). Поиск А в базе знаний организуется различными способами. Можно, например, сначала искать вершину а. Если в базе знаний такой вершины нет, то поиск заканчивается неудачей. Если вершина а найдена, то ищутся все выходящие из нее дуги, помеченные отношением R3, так как в образце справа от этой дуги стоит вершина x, на месте которой в базе знаний может находиться любая вершина. Если из а не выходит ни одной дуги, помеченной отношением R3, то поиск заканчивается неудачей. Но если такие дуги есть, то происходит переход во все вершины, с которыми вершину а связывает отношение R3, т.е. возникает параллельный процесс поиска. В примере произойдет переход от вершины а к вершинам b и f, из которых начинается поиск выходящих из них дуг, помеченные отношением R1, ведущих в любую вершину, так как в образце далее стоит вершина, которой соответствует свободная переменная y. Далее процесс продолжается аналогичным образом. В примере поиск оказывается успешным. После нахождения А в семантической сети происходит замена, которая определяется правой частью образца. В результате возникает трансформированная сеть (рис. 2в).

Продукция АДЮВЗ может соответствовать процедуре нахождения закономерностей по эмпирическим данным. Логический блок на основании просмотра и анализа данных выдвигает гипотезы и наличии закономерностей и, убедившись в их приемлемости и достаточной обоснованности, записывает их в базу знаний. Аналогично можно интерпретировать и иные типы продукций из таблицы 1.

Логический подход. Представление простых фактов в логических системах

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

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

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

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

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

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

Синтаксис логики предикатов.

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

Логика предикатов, называемая также логикой первого порядка, допускает четыре типа выражений.

  • Константы. Они служат именами индивидуумов (в отличие от имен совокупностей): объектов, людей или событий. Константы представляются символами вроде Жак_2 (добавление 2 к слову Жак указывает на вполне определенного человека среди людей с таким именем), Книга_22, Посылка_8.
  • Переменные. Обозначают имена совокупностей, таких как человек, книга, посылка, событие. Символ Книга_22 представляет вполне определенный экземпляр, а символ книга указывает либо множество "всех книг", либо "понятие книги". Символами x,y,z представлены имена совокупностей (определенных множеств или понятий).
  • Предикатные имена. Они задают правила соединения констанат и переменных, например правила грамматики, процедуры, математические операции. Для предикативных имен используются символы наподобие следующих: Фраза, Посылать, Писать, Плюс, Разделить. Предикатное имя иначе называется предикатной константой.
  • Функциональные имена представляют такие же правила, как и предикаты. Чтобы не спутать с предикатными именами, функциональные имена пишут одними строчными буквами: фраза, посылать, писать, плюс, разделить. Их называют так же функциональными константами.

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

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

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

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

  • По русски: Жак посылает книгу Мари,
    Логически: Посылка (Жак_2, Мари_4, Книга_22).
  • По русски: Каждый человек прогуливается,
    Логически: " x ( Человек(x) É Прогуливается(x)).
  • По русски: Некоторые люди прогуливаются,
    Логически: $ x (Человек(x) Ù Прогуливается(x)).

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

  • По русски: Ни один человек не прогуливается,
    Логически: Ø ($ x (Человек(x) Ù Прогуливается(x))).

Литература

  1. F. Hayes-Roth, N. Jacobstein. The State of Enowledge-Based Systems. Communications of the АСМ, March, 1994, v.37, n.3, рр.27-39.
  2. Р. Harmon. The Size of the Commercial AI Market in the US. Intelligent Software Strategies. 1994, v.10, n.1, рр. 1-6.
  3. Expert system saves 20 million L on pipeline management. C&I July, 1994, р.31.
  4. Д. Поспелов . "Справочник по ИИ том-2".


Планирование задач

На главную страницу

Лекция 6: Планирование задач

  1. Основные определения
  2. Комплексная схема нечеткого планирования
  3. Особенности планирования целенаправленных действий
  4. Оценка сложности задачи планирования
  5. Литература

Основные определения

Функционирование многих ИС носит целенаправленный характер . Типичным актом такого функционирования является решение задачи планирования пути достижения нужной цели из некоторой фиксированной начальной ситуации. Результатом решения задачи должен быть план действий - частично-упорядоченная совокупность действий. Такой план напоминает сценарий, в котором в качестве отношения между вершинами выступают отношения 'типа: "цель-подцель" "цель-действие", "действие-результат" и т. п.. Любой путь в этом сценарии, ведущий от вершины, соответствующей текущей ситуации, в любую из целевых вершин, определяет план действий.

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

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

При планировании в пространстве задач ситуация несколько иная. Пространство образуется в результате введения на множестве задач отношения типа: "часть - целое", "задача - подзадача", "общий случай - частный случай" и т. п. Другими словами, пространство задач отражает декомпозицию задач на подзадачи (цели на подцели). PR-проблема состоит в поиске декомпозиции исходной задачи на подзадачи, приводящей к задачам, решение которых системе известно. Например, ИС известно, как вычисляются значения sin x и cos x для любого значения аргумента и как производится операция деления. Если ИС необходимо вычислить tg x, то решением PR-проблемы будет представление этой задачи в виде декомпозиции tgx=a =sinx/cosx (кроме л:=л/2+k л).

Дадим классификацию методов, используемых при решении SS- и PR-проблем.

1. Планирование по состояниям. Представление задач в пространстве состояний предполагает задание ряда описаний: состояний, множества операторов и их воздействий на переходы между состояниями, целевых состояний. Описания состояний могут представлять собой строки символов, векторы, двухмерные массивы, деревья, списки и т. п. Операторы переводят одно состояние в другое. Иногда они представляются в виде продукций А=>В, означающих, что состояние А преобразуется в состояние В.

Пространство состояний можно представить как граф, вершины которого помечены состояниями, а дуги-операторами. Если некоторая дуга направлена от вершины ni, к вершине n,, то п, называется дочерней, а nj;-родительской вершинами

Последовательность вершин ni1, ni2, ... ,nik , в которой каждая ni-дочерняя вершина для вершины nij-1 , /=2,..., k, называется путем длиной k от вершины ni1, к вершине nik .

Таким образом, проблема поиска решения задачи <А,В> при планировании по состояниям представляется как проблема поиска на графе пути из A в B. Обычно графы не задаются, а генерируются по мере надобности.

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

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

Алгоритм кратчайших путей Мура. Исходная вершина x0 помечается числом 0. Пусть в ходе работы алгоритма на текущем шаге получено множество дочерних вершин Г(xi) вершины xi . Тогда из него вычеркиваются все ранее полученные вершины, оставшиеся помечаются меткой, увеличенной на единицу по сравнению с меткой вершины xi, и от них проводятся указатели к xi. Далее, на множестве помеченных вершин, еще не фигурирующих в качестве адресов указателей, выбирается вершина с наименьшей меткой и для нее строятся дочерние вершины. Разметка вершин повторяется до тех пор, пока не будет получена целевая вершина.

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

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

Алгоритм Харта, Нильсона и Рафаэля. В алгоритме объединены оба критерия: стоимость пути до вершины g(x) и стоимость пути от вершины h(x) - в аддитивной оценочной функции f (x) = g (x) + h (x). При условии h(x)<hp(x), где hp(x)- действительное расстояние до цели, алгоритм гарантирует нахождение оптимального пути.

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

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

Поиск планирования в пространстве задач заключается в последовательном сведении исходной задачи к все более простым до тех пор, пока не будут получены только элементарные задачи. Частично упорядоченная совокупность таких задач составит решение исходной задачи. Расчленение задачи на альтернативные множества подзадач удобно представлять в виде И/ИЛИ-графа. В таком графе всякая вершина, кроме концевой, имеет либо конъюнктивно связанные дочерние вершины (И-вершина), либо дизъюнктивно связанные (ИЛИ-вершина). В частном случае, при отсутствии И-вершин, имеет место граф пространства состояний. Концевые вершины являются либо заключительными (им соответствуют элементарные задачи), либо тупиковыми. Начальная вершина (корень И/ИЛИ-графа) представляет исходную задачу. Цель поиска на И/ИЛИ-графе - показать, что начальная вершина разрешима. Разрешимыми являются заключительные вершины (И-вершины), у которых разрешимы все дочерние вершины, и ИЛИ-вершины, у которых разрешима хотя бы одна дочерняя вершина. Разрешающий граф состоит из разрешимых вершин и указывает способ разрешимости начальной вершины. Наличие тупиковых вершин приводит к неразрешимым вершинам. Неразрешимыми являются тупиковые вершины, И-вершины, у которых неразрешима хотя бы одна дочерняя вершина, и ИЛИ-вершины, у которых неразрешима каждая дочерняя вершина.

Алгоритм Ченга и Слейгла. Основан на преобразовании произвольного И/ИЛИ-графа в специальный ИЛИ-граф, каждая ИЛИ-ветвь которого имеет И-вершины только в конце. Преобразование использует представление произвольного И/ИЛИ-графа как произвольной формулы логики высказываний с дальнейшим преобразованием этой произвольной формулы в дизъюнктивную нормальную форму. Подобное преобразование позволяет далее использовать алгоритм Харта, Нильсона и Рафаэля.

Метод ключевых операторов. Пусть задана задача <А, В> и известно, что оператор f обязательно должен входить в решение этой задачи. Такой оператор называется ключевым. Пусть для применения f необходимо состояние С, а результат его применения есть f(с). Тогда И-вершина <A,В> порождает три дочерние вершины: <A, С>, <С, f(c}> и <f(с), В>, из которых средняя является элементарной задачей. К задачам <A, С> и <f(с), В> также подбираются ключевые операторы, и указанная процедура редуцирования повторяется до тех пор, пока это возможно. В итоге исходная задача <A, В> разбивается на упорядоченную совокупность подзадач, каждая из которых решается методом планирования в пространстве состояний.

Возможны альтернативы по выбору ключевых операторов, так что в общем случае будет иметь место И/ИЛИ-граф. В большинстве задач удается не выделить ключевой оператор, а только указать множество, его содержащее. В этом случае для задачи <А, В> вычисляется различие между A и В, которому ставится в соответствие оператор, устраняющий это различие. Последний и является ключевым.

Метод планирования общего решателя задач (ОРЗ). ОРЗ явился первой наиболее известной моделью планировщика. Он использовался для решения задач интегрального исчисления, логического вывода, грамматического разбора и др. ОРЗ объединяет два основных принципа поиска:

анализ целей и средств и рекурсивное решение задач. В каждом цикле поиска ОРЗ решает в жесткой последовательности три типа стандартных задач: преобразовать объект A в объект В, уменьшить различие D между A и В, применить оператор f к объекту A. Решение первой задачи определяет различие D второй - подходящий оператор f, третьей - требуемое условие применения С. Если С не отличается от A, то оператор f применяется, иначе С представляется как очередная цель и цикл повторяется, начиная с задачи "преобразовать A в С". В целом стратегия ОРЗ осуществляет обратный поиск - от заданной цели В к требуемому средству ее достижения С, используя редукцию исходной задачи <A, В> к задачам <A, С> и <С, В>.

Заметим, что в ОРЗ молчаливо предполагается независимость различий друг от друга, откуда следует гарантия, что уменьшение одних различий не приведет к увеличению других.

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

Дедуктивный метод планирования системы QA3 , ОРЗ не оправдал возлагавшихся на него надежд в основном из-за неудовлетворительного представления задач. Попытка исправить положение привела к созданию вопросно-ответной системы QA3. Система рассчитана на произвольную предметную область и способна путем логического вывода ответить на вопрос: возможно ли достижение состояния В из A? В качестве метода автоматического вывода используется принцип резолюций. Для направления логического вывода QA3 применяет различные стратегии, в основном синтаксического характера, учитывающие особенности формализма принципа резолюций. Эксплуатация QA3 показала, что вывод в такой системе получается медленным, детальным, что несвойственно рассуждениям человека.

Метод продукций системы STRIPS . В этом методе оператор представляет продукцию Р, А=>В, где Р, А и В-множества ППФ исчисления предикатов первого порядка, Р выражает условия применения ядра продукции А=>В, где В содержит список добавляемых ППФ и список исключаемых ППФ, т. е. постусловия. Метод повторяет метод ОРЗ с тем отличием, что стандартные задачи определения различий и применения подходящих операторов решаются на основе принципа резолюций. Подходя-. щий оператор выбирается так же, как в ОРЗ, на основе принципа "анализ средств и целей". Наличие комбинированного метода планирования позволило ограничить процесс логического вывода описанием состояния мира, а процесс порождения новых таких описаний оставить за эвристикой "от цели к средству ее достижения".

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

Метод иерархической системы продукций решателя ABSTRIPS . В этом методе разбиение пространства поиска на уровни иерархии осуществляется с помощью детализации продукций, используемых в методе STRIPS. Для этого каждой литере ППФ, входящей в множество Р условий применения продукции, присваивается вес j, j=0, k, и на i-м уровне планирования, осуществляемом методом системы STRIPS, учитываются лишь литеры веса j. Таким образом, на k-ом уровне продукции описываются наименее детально, на нулевом-наиболее детально как в методе системы STRIPS. Подобное разбиение позволяет для планирования на j-м уровне использовать решение (j+1)-го уровня как скелет решения j-го уровня, что повышает эффективность поиска в целом.

Усовершенствованный метод планирования Ньюэлла и Саймона. В основу метода положена следующая идея дальнейшего совершенствования метода ОРЗ: задача решается сначала в упрощенной (за счет ранжировки различий) области планирования, а затем делается попытка уточнить решение применительно к более детальной, исходной проблемной области.

Комплексная схема нечеткого планирования

Недостатком большинства известных в настоящее время систем планирования является их жесткая привязка к схеме планирования. Любая из них всегда ищет решение либо SS-проблемы, либо PR-проблемы. Связано это с фиксацией формы представления информации для планирования. Для классических моделей SS- и PR-проблем эти формы различны. Ясно, однако, что человек в своей деятельности успешно комбинирует шаги планирования из решения SS- и PR-проблем. Вторым недостатком является детерминированность систем планирования. В реальных ИС детерминированность планирования, как правило, не имеет места. Обобщение нечетких SS- и PR-проблем заключается в допущении нечетких состояний и нечетких операторов перехода из состояния в состояние. Разбиение задачи на подзадачи имеет весовые коэффициенты на дугах со значениями из [0, 1], которые интерпретируются как достоверности решения соответствующих подпроблем. Достоверность решения PR-проблемы определяется как минимум достоверностей решения ее подпроблем.

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

Схемой SS-проблемы называется пара M=(S,G), где S-множество состояний, G-множество отображений g: S->S, называемых операторами. Путем из состояния s0эS в состояние srэS называется конечная последовательность p=(( s0, , g0), (s1, g1),...,(sk-1, gk-1) sk ) , такая, что giO si= si+1 для i=0,..., k-1. SS-проблема-это четверка Р=(S, G, i ,f), где (S, G)-схема SS-проблемы, i, fэS-соответственно начальное и заключительное состояние. Путь х, ведущий из i в f, есть решение Р, а множество всех подобных путей составляет множество решений.

Схемой PR-проблемы называется пара .N=(S , Г), где S -множество проблем, Г-множество отображений g : S ->S+, называемых операторами. Если РэS , p эS+, то g р(p)-отображение, представляющее проблему Р в виде цепочки подпроблем p = P1...Pn. Для схемы N=(S , Г) накрывающий путь q из проблемы s0 в конечное множество проблем Sk= {s1,...,sn} эS+ является конечной последовательностью, где q= ((x0 , y0), (x1, y1),..., (xk-1, yk-1), xk), xi э S+ для i=0,...,k, yэS+ для i=0,..., k-1, так что x0=s0, xkэS+k. PR-проблема представляет собой четверку Z=(S , Г, Ро, Ф), где (S , Г)-схема PR-проблемы, РоэS - начальная проблема, ФМ S -множество конечных проблем. Решение Z представляет собой накрывающий путь (S , Г) из Ро в Ф/xМ Ф, множество решений xz, есть множество всех решений Z.

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

Импликата проблемы Р есть пара (p, y), где p =PiP2... Pk - цепочка проблем, y -отображение из Хр1 C Хр2 ... C Хрk в Хр( Хрi обозначает множество решений Рi<). Импликативная схема есть тройка L =(Р, p , y ), такая, что Р - проблема, (p , y ) - импликата Р. Множество Т импликативных схем называется импликативной сетью. Множество проблем импликативной сети

W t={x|($ L )((L =(Р, p , y ))L ((х=Р)\/(х - символ p ))}.

Объединим синтаксис и семантику подхода, основанного на разбиении проблемы на подпроблемы. PR-проблема Z=(S , Г, Ро, Ф) представляет импликативную сеть Т тогда и только тогда, когда S =Wt и для каждого L =(Р, p , y )эT существует в точности одно g эГ, такое, что Рg =p , и для каждого g эГ, и для каждого Р из области определения g существует в точности одно L =(Р, p , Y )' T, такое,что p =Pg Проблема Р решена тогда и только тогда, когда Хp- непустое множество.

Если PR-проблема представляет импликативную сеть, то проблема Р0 разрешима. Для существования решения достаточно, чтобы импликативные схемы в импликативной сети Т существовали только для всех пар (xi, у,),i=0,..., k-1, входящих в накрывающий путь схемы PR-проблемы. В этом случае синтаксис и семантика PR-проблемы не совпадают. В данном случае PR-проблема частично представляет импликативную сеть Т.

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

Рассмотрим понятие, объединяющее подходы разбиения проблемы на под-проблемы и поиска в пространстве состояний. 1-проблемой (объединенной проблемой) называется четверка R=(B, Г, Р0, Т), где В-множество SS-проблем;

(В, Г)-схема PR-проблем; Р0эB -основная проблема;T-импликативная сеть, такая, что WTЗB"Ж. Кроме того, R есть решение SS-проблемы Р0. Учитывая связь между существованием импликативной сети и разрешимостью проблемы, легко показать, что если для заданной I-проблемы найден накрывающий путь х из Р0 на множество Ф'Н В, проблемы Ф' разрешимы как SS-проблемы, если х частично представляет импликативную сеть Т, то и проблема R разрешима как SS-проблема.

Рассмотрим головоломку "Ханойская башня" . Имеются три стержня 1, 2 и 3 и три диска различных размеров А, В, С с отверстием в центре, которые могут одеваться на стержни. В исходной позиции диски находятся на стержне 1; самый большой диск С-внизу, самый маленький диск А- наверху. Требуется перенести все диски на стержень 3, перемещая за один раз только один диск. Брать можно только самый верхний диск на стержне, причем его нельзя класть на диск, меньший по размерам. Используем для записи состояний и операторов классическую формализацию. Выражение ijk обозначает конфигурацию, при которой диск С находится на стержне i, диск В - на стержне j и диск А-на стержне k. Выражение xij обозначает действие, при котором диск х перемещается со стержня i на стержень j. С помощью этого формализма можно просто записать все состояния и переходы головоломки в виде треугольного графа, где вершины соответствуют расположению дисков на стержнях, а дуги-возможным перекладываниям дисков (рис.1). На этой головоломке легко проиллюстрировать все основные понятия обобщенной стратегии проблем.

Представим головоломку в виде модели I-проблемы. Рассмотрим I-проблему R=(B, Г, P0T), где B={Р0, P1,...,P9}; Г={g }; T=={L1,L2,L3}. SS-проблемы Р0,P1...,P9 определяются следующим образом. На рис. 1 показана схема SS-проблемы M==(S, G), где

P0=(S, G, 111, 333), P1=(S, G, 111, 122), P2=(S, G, 122, 322),

Рз=(S, G, 322, 333), P4=(S, G, 111, 113), P5,=(S, G, 113, 123),

P6==(S, G, 123, 122), P7=(S, G, 322, 321), P8=(S, G, 321, 331),

P9=(S G, 331,333).

Схема PR-проблемы N= (В, Г) приведена на рис. 2; импликативная сеть Т- на рис.3, причем L1=(P0, P1Р2Р3, Y), L2= (P1, P4P5P6, Y), L з== (Р3, P7P8P9,Y ), где Y (x1,x2,x3)=x1x2x3.

Проблемы Р2 и P4-P9 решаются перекладыванием одного диска и являются элементарными. Проблемы P1 и Р3 решаются с помощью манипуляций только с дисками В и А и являются более простыми, чем Р0. Проблемы P1 и Р3 решаются, а проблема Р0 сводится к P1, P2 и Р3 аналогичной манипуляцией с дисками, синтаксис которой выражен оператором g, а семантика - отображением Y .

Представление этой головоломки в виде PR-проблемы (рис.2) является более компактным и наглядным, чем представление в виде SS-проблемы (рис.1), а представление в виде I-проблемы (рис..3) сочетает достоинство обоих и показывает взаимосвязь подпроблем и тех действий, которые нужно выполнить, чтобы решить головоломку.

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

неоднозначны.

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

Нечеткой SS-проблемой назовем SS-проблему, у которой i , f-нечеткие множества, операторы g эГ-нечеткие матрицы, a-решением нечеткой SS-проблемы называется путь g=g1...gn,giэG,i=1,...,n, такой, что iOg1O... ... OgnOf? a , где О - максимальное произведение нечетких матриц.

Нечеткой PR-проблемой называется PR-проблема, у которой элементам g эГ приписывается степень принадлежности m g (p )э[0,1], a-решением нечеткой PR-проблемы называется решение PR-проблемы, для которой mingij? a,gij эyi.

Накрывающий путь в этом случае называется накрывающим a-путем. Степень принадлежности m g ( p ) интерпретируется как степень возможности разбиения проблемы на подпроблемы.

Нечеткой импликативной схемой называется импликативная схема, все отображения Y которой имеют степень принадлежности m Y ((p )э[0,1]. Степень принадлежности интерпретируется как возможность получения решения проблемы из решений соответствующих подпроблем. Нечеткой импликативной сетью называется импликативная сеть с нечеткими импликативными схемами.Нечеткая PR-проблема представляет нечеткую импликативную сеть, если кроме обычных условий для импликативной сети выполняется неравенство m Y (p )? m g (p ) ? a ,

т. е. возможность разбиения на подпроблемы не меньше возможности получения решения для каждой пары соответствующих Y и g.

Аналогично определяется нечеткая I-проблема. Но построить a-решение нечеткой PR-проблемы по a-решениям ее нечетких подпроблем можно лишь в частных случаях и при наложении дополнительных условий. Пусть задана нечеткая PR-проблема, где S-нечеткие SS-проблемы, и существует простейшее a-решение Z, т.е.такое p э S +,что m g p ? a,и если p =P1..Pn,то все проблемы Pi a-разрешимы,

где Pi=(Si,Gi,Ji,Fi ).a-решение проблемы P0 существует при m Y (p )? m g (p )? a для импликативной сети.Запишем более конструктивное условие для этого.Пусть для всех i оператор gi есть a-путь решения проблемы Piи Fi=Ji+1.Тогда,если выполняется max m [FnЗ (Fn-1З (...F1З (J o g1)o g2)...)o gn)]? a и g=g1...gn,то g- a-решение SS-проблемы P0.

Особенности планирования целенаправленных действий

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

Пусть задан некоторый предметный мир, в котором действие ИС состоит в достижении целевых ситуаций sk из некоторых исходных ситуаций sn c помощью планов действий;V=bi1...bin,где bi-исполнительный модуль из данного набора В0. Задать ситуацию s в таком мире-это значит указать свойства сiО. С предметов аkО A0 и отношения между ними rpО R0, которые имели, имеют или будут иметь место в момент t. Модель предметного мира для такого действия ИС можно представить в виде Mо=<Aо, Во, Со, Ro>, а задачу планирования действий в мире Мо следующим образом: заданы исходная sn и целевая sk" ситуации, необходимо построить из исполнительных модулей biО Во план действий V, который, будучи примененным к Sn, позволяет достичь Sk.

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

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

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

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

Итак, основу рассуждений ИС по планированию действий составляют структурированные знания и направленный эвристический поиск.

Пусть C1 - множество, получаемое огрублением свойств сО С0 , В1 - множество элементарных задач, получаемое переименованием исполнительных модулей biО B0, A1 ? A и R1? Ro. Тогда модель мира тактических задач можно представить в виде Mo=<A1, B1, C1, R1>, постановку тактической задачи р-

в виде пары <sn, sk >, а ее решение-в виде совокупности V = Ь1 , ..., Ьin. Очевидно, благодаря указанному огрублению в мире M1 становятся неразличимыми отдельные состояния предметов и исполнительных модулей. Однако подобное упрощение, вызываемое "грубостью" органов чувств ИС, еще не позволяет значительно снизить размерность пространства поиска решений V, поэтому необходимо дальнейшее обобщение M1 уже на понятийном уровне.

В мире M1 тактические ситуации s описываются, как и ситуации s в мире M0, через свойства объектов и отношения между ними. Однако такие описания не носят целостного характера, так как не содержат в явном виде смысловых структур. Выявление таких обобщенных структур, а также формирование соответствующих им тактических ситуаций s осуществляются на основе понятий, которыми располагает ИС, и означают осмысливание ею сложившихся или целевых ситуаций s с точки зрения этих понятий, используемых в этом случае как программы-тесты. Таким образом, в мире M2 указанные ситуации s представляются в виде укрупненных предметов ak О A2, свойства которых ci О C2 и отношения r2 О R2 между которыми, как и сами укрупненные предметы, определяются понятиями-тестами. Аналогично обстоят дела и с решениями V в мире M1. Целостное описание V означает описание этих решений именно как типовых задач. Таким образом, в мире M2 имеют место типовые задачи bi О B2.

Оценки сложности задачи планирования

Приведем ряд результатов, касающихся сложности решения задач планирования.

1. Анализ вычислительных задач оказывается PSPACE-полной проблемой даже при условии, что "пустых" величин W нет .

2. Для вычислительных моделей без функциональных величин, т. е. с пустыми Db и F, проблема анализа вычислительных задач оказывается: а) PSPACE-полной для Н, содержащих функциональные и операторные зависимости без W ; б) NP-полной для Н, содержащих только функциональные и вариантные зависимости без "пустой" величины W ; в) полиномиальной (по времени работы планировщика) для Н, содержащих только функциональные и неявные зависимости; г) можно построить планировщики с линейным временем работы для Н только с функциональными зависимостями без W и для Н с функциональными и неявными зависимостями .

В системе ПГИЗ Db и F пусты, а в Н имеются только функциональные и операторные зависимости без "пустой" величины W. В системе автоматического синтеза программ СПОРА используется исчисление предикатов, для которого разработана специальная стратегия вывода .

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

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

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

Функциональной зависимости (F->Y1), где F -функциональная величина типа (X->-Y), предполагающей предварительный синтез процедуры вычисления F, входными параметрами которой являются величины из списка X.

Операторных зависимостей, предполагающих синтез т процедур с входами "условиями подзадач" X1, Х2, ..., Хь-

Вариантных зависимостей, предполагающих, что создаются две ветви вычислений: для первой известны значения всех величин из списка Y1, для второй - из списка У2.

Рассмотрим простой (но типичный) пример. Пусть имеют место функциональная зависимость D1: (A, В, СR Е) и операторные зависимости D2: ((СR Е ) R Е1), D3:(( BR Е1))R Е2)), D4: ((AR Е2 ) R Е3). Необходимо найти Ез. Для этого следует решить подзадачу (AR Е2 ). Если воспользоваться зависимостью D3, то придем к поиску решения новой подзадачи ( BR Е1). Если использовать зависимость D2, то придем к необходимости решения подзадачи ( CR Е), которая согласно D1 разрешима только тогда, когда A и В известны. Степень взаимодействия подзадач в этом примере равна трем. Процесс является типичной схемой планирования в пространстве задач .

Для планировщиков, работающих в "исчислении вычислительных задач;", синтез решения вычислительной задачи происходит за время hqrl/r!, где h - константа, l-длина записи задачи, определяемая как суммарное число вхождений имен используемых величин в F и H, q- общее число "различных" аргументов величин из "условия подзадач" в операторных зависимостях из H и "условий вариантов" в вариантных зависимостях из H, r-минимальная степень взаимодействия подзадач в исходной задаче . Эта оценка носит квазиоптимальный характер. Планировщик работает долго только на тех задачах, которые не являются естественными, так как требуют предельного переплетения между собой всех подзадач, на которые разбивается исходная задача. Эксперименты показывают, что для задач, встречающихся на практике, время работы планировщика является полиномиальным. Память, необходимая для работы планировщика в "исчислении вычислительных задач", оценивается величиной bl2, где Ь - константа. Если в Н нет вариантных зависимостей, то требуется линейный объем памяти dl, где d-константа .

В известных сейчас планировщиках получаемые программы далеки от оптимальных. Наблюдается тенденция ухудшения качества программ при уменьшении времени работы планировщика. При этом синтезировать оптимальные последовательные программы труднее, чем оптимальные параллельные программы. Это обстоятельство в связи с развитием ЭВМ новой архитектуры, ориентированной на параллельные процессы, может оказаться выгодным. Например, задача поиска минимальных по времени последовательного исполнения программ для решения вычислительных задач, у которых Db пусто, а Н состоит только из функциональных зависимостей W , оказывается NP-полной в сильном смысле . С другой стороны, в "исчислении вычислительных задач" при условии, что Db пусто, а Н состоит из функциональных и неявных зависимостей, можно за линейное время kl (k - константа) синтезировать программу, параллельное выполнение которой требует минимального для данной задачи времени .

В системе ПРИЗ и ее модификациях вычислительная задача считается разрешимой, если соответствующая ей формула выводима в позитивном фрагменте интуиционистского исчисления высказываний , т. е. в том и только том случае, когда достигается успех планировщиком системы ПРИЗ. Для "исчисления вычислительных задач" возможны две семантики для разрешимости .

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

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

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

Во многих ИС используются планировщики, возможности которых существенно шире, чем у планировщика системы ПРИЗ, или того, который применяется в "исчислении вычислительных задач". Исчисления, с которыми имеют дело многие планировщики систем автоматизированного проектирования, планирования и управления, шире интуиционистских исчислений высказываний. При этом используются эвристические соображения, не имеющие аналогов в тех соотношениях, в которых описывались вычислительные модели. Примером может служить планировщик системы МАВР, предназначенной для ИС автоматизированного проектирования . При его работе возникают ситуации, не разрешимые в теории, которая описывалась выше. Такие случаи заставляют искать иные пути построения системы для поиска планов действий.

Литература

  1. Аверкин А.Н. и др. .Обобщенные стратегии в решателях проблем.
  2. Диковский А.Я. , Канович М.И. . Вычислительные модели с разделяемыми подзадачами.
  3. Ефимов Е.И. Решатели интеллектуальных задач.
  4. Эрлих А.И. . Диалоговая система моделирования альтернатив и выбора решений в проектировании / Представление знаний в человеко-машинных и робото-технических системах.
  5. Файкс Р, Нильсон Н. . Система STRIPS - новый подход к применению доказательства при решении задач / / Интегральные роботы.
  6. Ньюэлл А. Эмпирические исследования машин "Логик-теоретик": пример изучения эвристики.


Экспертные системы

На главную страницу

Лекции 7-8: Экспертные системы

  1. Назначение экспертных систем
  2. Структура экспертных систем
  3. Этапы разработки экспертных систем
  4. Интерфейс с конечным пользователем
  5. Представление знаний в ЭС
  6. Уровни представления и уровни детальности
  7. Организация знаний в рабочей системе
  8. Организация знаний в базе данных
  9. Методы поиска решений в экспертных системах
  10. Инструментальный комплекс для создания статических экспертных систем (на примере интегрированного комплекса ЭКО)
  11. Средства представления знаний и стратегии управления
  12. Инструментальный комплекс для создания экспертных систем реального времени (на примере интегрированной среды g2-gensym corp., Сша)

Назначение экспертных систем

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

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

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

  • технология ЭС является важнейшим средством в решении глобальных проблем традиционного программирования: длительность и, следовательно, высокая стоимость разработки сложных приложений;

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

  • объединение технологии ЭС с технологией традиционного программирования добавляет новые качества к программным продуктам за счет: обеспечения динамичной модификации приложений пользователем, а не программистом; большей "прозрачности" приложения (например, знания хранятся на ограниченном ЕЯ, что не требует комментариев к знаниям, упрощает обучение и сопровождение); лучшей графики; интерфейса и взаимодействия.

По мнению ведущих специалистов , в недалекой перспективе ЭС найдут следующее применение:

  • ЭС будут играть ведущую роль во всех фазах проектирования, разработки, производства, распределения, продажи, поддержки и оказания услуг;

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

ЭС предназначены для так называемых неформализованных задач, т.е. ЭС не отвергают и не заменяют традиционного подхода к разработке программ, ориентированного на решение формализованных задач.

Неформализованные задачи обычно обладают следующими особенностями:

  • ошибочностью, неоднозначностью, неполнотой и противоречивостью исходных данных;

  • ошибочностью, неоднозначностью, неполнотой и противоречивостью знаний о проблемной области и решаемой задаче;

  • большой размерностью пространства решения, т.е. перебор при поиске решения весьма велик;

  • динамически изменяющимися данными и знаниями.

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

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

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

Коммерческие успехи к фирмам-разработчикам систем искусственного интеллекта (СИИ) пришли не сразу. На протяжении 1960 - 1985 гг. успехи ИИ касались в основном исследовательских разработок, которые демонстрировали пригодность СИИ для практического использования. Начиная примерно с 1985 г. (в массовом масштабе с 1988 - 1990 гг.), в первую очередь ЭС, а в последние годы системы, воспринимающие естественный язык (ЕЯ-системы), и нейронные сети (НС) стали активно использоваться в коммерческих приложениях.

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

Причины, приведшие СИИ к коммерческому успеху, следующие.

Интегрированность. Разработаны инструментальные средства искусственного интеллекта (ИС ИИ), легко интегрирующиеся с другими информационными технологиями и средствами (с CASE, СУБД, контроллерами, концентраторами данных и т.п.).

Открытость и переносимость. ИС ИИ разрабатываются с соблюдением стандартов, обеспечивающих открытость и переносимость [14].

Использование языков традиционного программирования и рабочих станций. Переход от ИС ИИ, реализованных на языках ИИ (Lisp, Prolog и т.п.), к ИС ИИ, реализованным на языках традиционного программирования (С, C++ и т.п.), упростил обеспечение интегриро-ванности, снизил требования приложений ИИ к быстродействию ЭВМ и объемам оперативной памяти. Использование рабочих станций (вместо ПК) резко увеличило круг приложений, которые могут быть выполнены на ЭВМ с использованием ИС ИИ.

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

Проблемно/предметно-ориентированные ИС ИИ. Переход от разработок ИС ИИ общего назначения (хотя они не утратили свое значение как средство для создания ориентированных ИС) к проблемно/предметно-ориентированным ИС ИИ [9] обеспечивает: сокращение сроков разработки приложений; увеличение эффективности использования ИС; упрощение и ускорение работы эксперта; повторную используемость информационного и программного обеспечения (объекты,классы,правила,процедуры).

Структура экспертных систем

Типичная статическая ЭС состоит из следующих основных компонентов (рис. 1.):

  • решателя (интерпретатора);
  • рабочей памяти (РП), называемой также базой данных (БД);
  • базы знаний (БЗ);
  • компонентов приобретения знаний;
  • объяснительного компонента;
  • диалогового компонента.

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

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

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

Компонент приобретения знаний автоматизирует процесс наполнения ЭС знаниями, осуществляемый пользователем-экспертом.

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

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

В разработке ЭС участвуют представители следующих специальностей:

эксперт в проблемной области, задачи которой будет решать ЭС;

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

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

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

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

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

Программист разрабатывает ИС (если ИС разрабатывается заново), содержащее в пределе все основные компоненты ЭС, и осуществляет его сопряжение с той средой, в которой оно будет использовано.

Экспертная система работает в двух режимах: режиме приобретения знаний и в режиме решения задачи (называемом также режимом консультации или режимом использования ЭС).

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

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

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

"Почему система задает тот или иной вопрос?", "как ответ, собираемый системой, получен?".

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

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

Подчеркнем, что структура ЭС, представленная на рис. 1.1 и 1.2, отражает только компоненты (функции), и многое остается "за кадром". На рис. 1.3 приведена обобщенная структура современного ИС для создания динамических ЭС, содержащая кроме основных компонентов те возможности, которые позволяют создавать интегрированные приложение в соответствии с современной технологией программирования.

Этапы разработки экспертных систем

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

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

  • существуют эксперты в данной области, которые решают задачу значительно лучше, чем начинающие специалисты;

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

  • эксперты способны вербализовать (выразить на естественном языке) и объяснить используемые ими методы, в противном случае трудно рассчитывать на то, что знания экспертов будут "извлечены" и вложены в ЭС;

  • решение задачи требует только рассуждений, а не действий;

  • задача не должна быть слишком трудной (т.е. ее решение должно занимать у эксперта несколько часов или дней, а не недель);

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

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

Использование ЭС в данном приложении может быть возможно, но не оправдано. Применение ЭС может быть оправдано одним из следующих факторов:

  • решение задачи принесет значительный эффект, например экономический;

  • использование человека-эксперта невозможно либо из-за недостаточного количества экспертов, либо из-за необходимости выполнять экспертизу одновременно в различных местах;

  • использование ЭС целесообразно в тех случаях, когда при передаче информации эксперту происходит недопустимая потеря времени или информации;

  • использование ЭС целесообразно при необходимости решать задачу в окружении, враждебном для человека.

Приложение соответствует методам ЭС, если решаемая задача обладает совокупностью следующих характеристик:

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

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

  3. задача должна быть достаточно сложна, чтобы оправдать затраты на разработку ЭС. Однако она не должна быть чрезмерно сложной (решение занимает у эксперта часы, а не недели), чтобы ЭС могла ее решать;

  4. задача должна быть достаточно узкой, чтобы решаться методами ЭС, и практически значимой.

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

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

В ходе работ по созданию ЭС сложилась определенная технология их разработки, включающая шесть следующих этапов (рис. 1.4):

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

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

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

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

Интерфейс с конечным пользователем

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

RTworks не обладает собственными средствами для отображения текущего состояния управляемого процесса. Разработчик приложения вынужден использовать систему Dataview фирмы VI Corporation, что в значительной степени ограничивает его возможности.

Интерфейс с пользователем TDC Expert ограничен возможностями системы TDC 3000, т.е. взаимодействие с конечным пользователем

ограничивается текстовым режимом работы.

Представление знаний в экспертных системах

Первый и основной вопрос, который надо решить при представлении знаний, - это вопрос определения состава знаний, т.е. определение того, "ЧТО ПРЕДСТАВЛЯТЬ" в экспертной системе. Второй вопрос касается того, "КАК ПРЕДСТАВЛЯТЬ" знания. Необходимо отметить, что эти две проблемы не являются независимыми. Действительно, выбранный способ представления может оказаться непригодным в принципе либо неэффективным для выражения некоторых знаний.

По нашему мнению, вопрос "КАК ПРЕДСТАВЛЯТЬ" можно разделить на две в значительной степени независимые задачи: как организовать (структурировать) знания и как представить знания в выбранном формализме.

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

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

  • определение состава представляемых знаний;
  • организацию знаний;
  • представление знаний, т.е. определение модели представления.

Состав знаний ЭС определяется следующими факторами:

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

В соответствии с общей схемой статической экспертной системы (см. рис. 1.1) для ее функционирования требуются следующие знания:

  • знания о процессе решения задачи (т.е. управляющие знания), используемые интерпретатором (решателем);

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

  • знания о способах представления и модификации знаний, используемые компонентом приобретения знаний;

  • поддерживающие структурные и управляющие знания, используемые объяснительным компонентом.

Для динамической ЭС, кроме того, необходимы следующие знания:

  1. знания о методах взаимодействия с внешним окружением;

  2. знания о модели внешнего мира.

Зависимость состава знаний от требований пользователя проявляется в следующем:

  • какие задачи (из общего набора задач) и с какими данными хочет решать пользователь;

  • каковы предпочтительные способы и методы решения;

  • при каких ограничениях на количество результатов и способы их получения должна быть решена задача;

  • каковы требования к языку общения и организации диалога;

  • какова степень общности (конкретности) знаний о проблемной области, доступная пользователю;

  • каковы цели пользователей.

Состав знаний о языке общения зависит как от языка общения, так и от требуемого уровня понимания.

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

Интерпретируемые знания можно разделить на предметные знания, управляющие знания и знания о представлении. Знания о представлении содержат информацию о том, каким образом (в каких структурах) в системе представлены интерпретируемые знания.

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

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

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

  1. метазнания в виде стратегических метаправил используются для выбора релевантных правил ;

  2. метазнания используются для обоснования целесообразности применения правил из области экспертизы;

  3. метаправила используются для обнаружения синтаксических и семантических ошибок в предметных правилах;

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

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

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

  • организация знаний по уровням представления и по уровням детальности;

  • организация знаний в рабочей памяти;

  • организация знаний в базе знаний.

Уровни представления и уровни детальности

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

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

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

Организация знаний в рабочей системе

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

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

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

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

Организация знаний в базе данных

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

Связность {агрегация) знаний является основным способом, обеспечивающим ускорение поиска релевантных знаний. Большинство специалистов пришли к убеждению, что знания следует организовывать вокруг наиболее важных объектов (сущностей) предметной области. Все знания, характеризующие некоторую сущность, связываются и представляются в виде отдельного объекта. При подобной организации знаний, если системе потребовалась информация о некоторой сущности, то она ищет объект, описывающий эту сущность, а затем уже внутри объекта отыскивает информацию о данной сущности. В объектах целесообразно выделять два типа связок между элементами: внешние и внутренние. Внутренние связки объединяют элементы в единый объект и предназначены для выражения структуры объекта. Внешние связки отражают взаимозависимости, существующие между объектами в области экспертизы. Многие исследователи классифицируют внешние связки на логические и ассоциативные. Логические связки выражают семантические отношения между элементами знаний. Ассоциативные связки предназначены для обеспечения взаимосвязей, способствующих ускорению процесса поиска релевантных знаний.

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

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

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

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

Методы поиска решений в экспертных системах

Методы решения задач, основанные на сведении их к поиску, зависят от

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

  • размер, определяющий объем пространства, в котором предстоит искать решение;

  • изменяемость области, характеризует степень изменяемости области во времени и пространстве (здесь будем выделять статические и динамические области);

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

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

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

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

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

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

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

  • методы поиска в иерархических пространствах - методы, предназначенные для работы в областях большой размерности;

  • методы поиска при неточных и неполных данных ;

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

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

Инструментальный комплекс для создания статических экспертных систем (на примере интегрированного комплекса ЭКО)

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

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

На основе комплекса ЭКО было разработано более 100 прикладных экспертных систем. Среди них отметим следующие:

  • поиск одиночных неисправностей в персональном компьютере;

  • оценка состояния гидротехнического сооружения (Чарвакская ГЭС);

  • подготовка деловых писем при ведении переписки с зарубежными партнерами;

  • проведение скрининговой оценки иммунологического статуса;

  • оценка показаний микробиологического обследования пациента, страдающего неспецифическими хроническими заболеваниями легких;

Средства представления знаний и стратегии управления

Комплекс ЭКО включает три компонента.

Ядром комплекса является интегрированная оболочка экспертных систем ЭКО, которая обеспечивает быстрое создание эффективных приложений для решения задач анализа в статических проблемных средах типа 1 и 2.

При разработке средств представления знаний оболочки преследовались две основные цели: эффективное решение достаточно широкого и практически значимого класса задач средствами персональных компьютеров; гибкие возможности по описанию пользовательского интерфейса и проведению консультации в конкретных приложениях. При представлении знаний в оболочке используются специализированные (частные) -утверждения типа "атрибут - значение" и частные правила, что позволяет исключить ресурсоемкую операцию сопоставления по образцу и добиться эффективности разрабатываемых приложений. Выразительные возможности оболочки удалось существенно расширить за счет интегрированности, обеспечиваемой путем вызова внешних программ через сценарий консультации и стыковки с базами данных (ПИРС и dBase IV) и внешними программами. В оболочке ЭКО обеспечивается слабая структуризация БЗ за счет ее разделения на отдельные компоненты - для решения отдельных подзадач в проблемной среде - модели (понятию "модель" ЭКО соответствует понятие "модуль" базы знаний системы G2).

С точки зрения технологии разработки ЭС оболочка поддерживает подходы, основанные на поверхностных знаниях и структурировании процесса решения.

Оболочка функционирует в двух режимах: в режиме приобретения знаний и в режиме консультации (решения задач). В первом режиме разработчик ЭС средствами диалогового редактора вводит в БЗ описание конкретного приложения в терминах языка представления знаний оболочки. Это описание компилируется в сеть вывода с прямыми адресными ссылками на конкретные утверждения и правила. Во втором режиме оболочка решает конкретные задачи пользователя в диалоговом или пакетном режиме. При этом решения выводятся от целей к данным (обратное рассуждение).

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

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

Инструментальный комплекс для создания экспертных систем реального времени (на примере интегрированной среды g2-gensym corp., Сша)

История развития ИС для создания ЭС реального времени началась в 1985 г., когда фирма Lisp Machine Inc. выпустила систему Picon для символьных ЭВМ Symbolics. Успех этого ИС привел к тому, что группа ведущих разработчиков Picon в 1986 г. образовала частную фирму Gensym, которая, значительно развив идеи, заложенные в Picon, в 1988 г. вышла на рынок с ИС под названием G2, версия 1.0. В настоящее время функционирует версия 4.2 и готовится к выпуску версия 5.0.

Основное предназначение программных продуктов фирмы Gensym (США) - помочь предприятиям сохранять и использовать знания и опыт их наиболее талантливых и квалифицированных сотрудников в интеллектуальных системах реального времени, повышающих качество продукции, надежность и безопасность производства и снижающих производственные издержки. О том, как фирме Gensym удается справиться с этой задачей, говорит хотя бы то, что сегодня ей принадлежат 50% мирового рынка экспертных систем, используемых в системах управления.

С отставанием от Gensym на 2 - 3 года другие фирмы начали создавать свои ИС для ЭС РВ. С точки зрения независимых экспертов NASA, проводивших комплексное исследование характеристик и возможностей некоторых из перечисленных систем, в настоящее время наиболее продвинутым ИС, безусловно, остается G2 (Gensym, США); следующие места со значительным отставанием (реализовано менее 50% возможностей G2) занимают RTWorks - фирма Talarian (США), COMDALE/C (Comdale Techn. - Канада), COGSYS (SC - США), ILOG Rules (ILOG - Франция).

Классы задач, для которых предназначена G2 и подобные ей системы:

  • мониторинг в реальном масштабе времени;

  • системы управления верхнего уровня;

  • системы обнаружения неисправностей;

  • диагностика;

  • составление расписаний;

  • планирование;

  • оптимизация;

  • системы - советчики оператора;

  • системы проектирования.

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

  • проблемно/предметная ориентация;

  • следование стандартам;

  • независимость от вычислительной платформы;

  • совместимость снизу-вверх с предыдущими версиями;

  • универсальные возможности, не зависимые от решаемой задачи;

  • обеспечение технологической основы для прикладных систем;

  • комфортная среда разработки;

  • поиск новых путей развития технологии;

  • распределенная архитектура клиент-сервер;

  • высокая производительность.

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

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

  • интеллектуальное управление производством - G2, G2 Diagnostic Assistant (GDA), NeurOn-Line (NOL), Statistical Process Control (SPC), BatchDesign_Kit;

  • оперативное планирование - G2, G2 Scheduling Toolkit (GST), Dynamic Scheduling Packadge (DSP);

  • разработка и моделирование производственных процессов - G2, ReThink, BatchDesign_Kit;

  • управление операциями и корпоративными сетями - G2, Fault Expert.

Несмотря на то, что первая версия системы G2 появилась не так давно - в 1988 г., ее даже в богатой Америке никто не назовет дешевой. G2 можно назвать бестселлером на рынке программных продуктов - на начало 1996 г. в мире было установлено более 5000 ее копий. Фирма Gensym обслуживает более 30 отраслей - от аэрокосмических исследований до производства пищевых продуктов. Список пользователей G2 выглядит как справочник Who-Is-Who в мировой промышленности. 25 самых крупных индустриальных мировых корпораций используют G2. На базе G2 написано более 500 действующих приложений.

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

Таблица 9.1 Платформы, на которых функционирует G2

Фирма-производитель | Вычислительная система | Операционная среда
Digital Equipment | VAX Зххх,4ххх,бххх, 7ххх, 8ххх,9ххх | VMS
 | DECstation Зххх, бххх | ULTRIX
 | DEC Alpha APX | Open VMS, OSF/1, Windows NT
SUN Microsystems | SUN=4 | Sun OS
 | SPARC 1,2, 10, LX, Classic | Sun OS/Solaris 1, Solaris 2.x
Hewlett Packard | НР9000/4хх, 7хх, 8хх | HP-UX
IBM | RISC 6000 | AIX
Data General | AViiON | DG/UX
Silicon Graphics | IRIS, INDIGO | IRIX
ПЭВМ | Intel 486/Pentium | Windows NT, Windows-95
Motorola | Motorola 88000 | UNIX
NEC | EWS 4800 | EWS-UX/V


Методы работы со знаниями

На главную страницу

Лекция 9: Методы работы со знаниями

  1. Основные определения
  2. Подготовительный этап
  3. Основной этап
  4. Системы приобретения знаний от экспертов
  5. Формализация качественных знаний
  6. Пример формализации качественных знаний

Основные определения

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

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

В когнитивной психологии изучаются формы репрезентации знаний (когнитивные структуры знаний) характерные для человека. Примерами могут служить [Хафман, 1986]: представление класса понятий через его элементы (например, понятие "птица" репрезентируется рядом чайка, воробей, скворец, ...) представление понятий класса с помощью базового прототипа, отражающего наиболее типичные свойства объектов класса (например, понятие "птица" репрезентируется прототипом нечто с крыльями, клювом, летает ...) представление с помощью признаков (для понятия "птица", например, наличие крыльев, клюва, двух лап, перьев).

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

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

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

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

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

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

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

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

Процесс взаимодействия инженера по знаниям (аналитика) с экспертом-специалистом включает три основных этапа.

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

Аналитику необходимо: глубоко познакомиться со специальной литературой по предметной области" чтобы не задавать очень "глупых" вопросов (просто "глупые" вопросы бывают чрезвычайно полезны), а также увеличить количество "пакетов ожиданий" [Шенк и др., 1987]; уметь слушать и грамотно задавать вопросы; настроиться на роль "ученикам, а не "экзаменатора"; разбираться в моделях когнитивной психологии, а также в моделях представления знаний, чтобы из знаний эксперта выделять четкие структуры.

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

Принадлежность научного работника к тому или иному типу определяется с помощью косвенных методик (тестов личности, интеллекта, когнитивных стилей. проектных методик). Автоматизация опроса и получения психологического портрета испытуемого реализована, например, в системе АВТАНТЕСТ [Гаври-лова. 1984].

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

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

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

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

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

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

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

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

Подготовительный этап

  1. Четкое определение задач проектируемой системы (сужение поля знаний): определение, что на входе и выходе; определение режима работ, консультации, обучение и др.
  2. Выбор экспертов: определение количества экспертов; выбор уровня компетентности (не всегда хорошо выбирать самый высокий уровень сразу); определение способов и возможности заинтересовать экспертов в работе; тестирование экспертов.
  3. Знакомство аналитика со специальной литературой в предметной области.
  4. Знакомство аналитика и экспертов (в дальнейшем для простоты будем считать, что эксперт один).
  5. Знакомство эксперта с популярной литературой по искусственному интеллекту (желательно, но необязательно).
  6. Попытка аналитика создать поле знаний первого приближения априорным знаниям из литературы (прототип поля знаний).

Основной этап

  1. "Накачка" поля знаний: а) в зависимости от предметной области выбор способа интервьюирования; б) протоколирование мыслей вслух или запись на магнитофон рассуждении эксперта (аналитик по возможности не должен пока вмешиваться в рассуждения).
  2. "Домашняя работа". Попытка аналитика выделить некоторые причинно-следственные связи в рассуждениях эксперта; построение словаря предметной области (возможно, на карточках) и подготовка вопросов к эксперту.
  3. "Подкачка" поля зрения. Обсуждение с экспертом прототипа поля знаний и домашней работы, а также ответы на вопросы аналитика.
  4. Формализация концептуальной модели.
  5. Построение поля знаний второго приближения.

Системы приобретения знаний от экспертов

Одно из первых рассмотрении интервью как метода инженерии знаний проведено в [Newel 1972], Проблемы, возникающие при извлечении экспертных знаний, некоторые психологи связывают с так называемой когнитивной защитой. В [Kelly, 1985] была развита теория человеческого познания, основанная на понятии "персональных конструктов", которые человек создает и пытается приспособить к реалиям мира. В [Bose, 1984] теория персональных конструктов использована для создания системы извлечения экспертных знаний и показала свою способность успешно преодолевать когнитивную защиту, т. е. нежелание экспертов достичь четкого и осознанного ими истолкования основных понятий, отношений между понятиями и приемов решения задач в интересующей инженера по знаниям проблемной области.

Методы интервьюирования эксперта предметной области знаний с использованием нескольких различных стратегий применены при создании системы TEIRESIAS [Davis, 1982]. В [Kahn et aL, 1984] выделено восемь различных стратегий интервью, в [Kahn et aL, 1985] на основе этих стратегий исследуется возможность автоматического интервьюирования. Автоматизации метода протокольного анализа посвящены работы [Waterman, 1971, 1973; Krippendorf, 1980].

В [Kahn et al. 1985] на примере диагностической системы MORE; описана техника интервьюирования, направленная на выяснение следующих сущностей, гипотез, симптомов, условий, связей и путей. Гипотеза - событие идентификация которого имеет своим результатом диагноз. Симптом-событие, являющееся следствием существования гипотезы, наблюдение которого приближает последующее принятие гипотезы. Условие - событие или некоторое множество событий, которое не является непосредственно симптоматическим для какой-либо гипотезы, но которое может иметь диагностическое значение для некоторых других событий. Связи-соединения сущностей (в том числе, других связей). Путь- выделенный тип связи, который соединяет гипотезы с симптомами. В соответствии с этим используются следующие стратегии интервью: дифференциация гипотез, различение симптомов, симптомная обусловленность, деление пути и др.

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

Аналогичные стратегии интервьюирования эксперта использованы при создании инструментальной диагностической системы ИДИС [Голубев и др., 1987].

В системе KRITON [Diederich et aL, 1987] для приобретения знаний используются два источника: эксперт с его знаниями, полученными на практике (эти знания, как правило, неполны, отрывочны, плохо структурированы); книжные знания, документы, описания инструкции (эти знания хорошо структурированы и фиксированы традиционными средствами). Для извлечения знаний из первого источника в KRITON применена техника интервью, использующая стратегии репертуарной решетки и разбиения на ступени. При этом применяется прием переключения стратегий: если при предъявлении тройки семантически связанных понятий эксперт не в состоянии назвать признак, отличающий два из них от третьего, система запускает стратегию разбиения на ступени и предпринимает попытку выяснения таксономической структуры этих понятий с целью выявления признаков, их различающих.

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

Анализ текста используется в KRITON для выявления хорошо структурированных знаний из книг, документов, описаний, инструкций.

В [Morik, 1987] описан метод выявления модели предметной области. Первая фаза-формирование инженером знаний грубой модели предметной области путем определения предикатов и сортов их возможных аргументов и сообщения системе фактов об области, выразимых этими предикатами. Система выявляет свойства предикатов и устанавливает отношения между ними, структурируя таким образом предметную область. На второй фазе с помощью метазнаний (общих структур), отражающих особенности человеческого мышления, осуществляется проверка соответствия фактов предикатам, индуктивный вывод правил из фактов, вывод правил из других правил.

В системах SIMER и ДИАПС [Осипов. 1987; Osipov et aL, 1987] основным методом приобретения знаний является автоматизированное интервьюирование эксперта, которое управляется знаниями, приобретенными системой. В системах SIMER и ДИАПС не выявляется предварительная модель области. Все объекты (события) и их атрибуты определяются в режиме прямого интервьюирования эксперта. Предполагается только, что на множестве объектов могут быть заданы ряд отношений из известного (конечного) множества: "элемент-множество", "часть - целое", "пример - прототип", отношения структурного сходства объектов, структурной иерархии и некоторые другие. Все отношения попарно различаются формальными свойствами. Так, отношений структурного сходства не обладает транзитивностью, но симметрично. Отношение структурной иерархии. напротив, не обладает симметричностью, однако транзитивно. На выяснение этих и ряда других свойств отношений и объектов направлено интервью.

В частности, для установления структурного сходства на первой фазе интервью для каждого вновь вводимого понятия эксперту предлагается указать (с помощью меню) те понятия предметной области, с которыми может быть связано данное (без спецификации отношения). Затем в процессе интервью для каждой пары понятий (из выделенных на первой фазе) связь специфицируется, устанавливаются свойства и тип отношения, в число элементов которого включается исследуемая пара. Так, для включения некоторой пары понятий Х и У. о которых эксперт сообщил, что Х влияет на У (например Х увеличивает возможность У), в число элементов некоторого отношения Я, обладающего среди прочих свойств симметричностью, необходимо задать эксперту вопрос: "Увеличивает ли У возможность ?". При положительном ответе на этот вопрос (и если прочие свойства уже установлены и удовлетворяют определению отношения Я) пара (X, У) включается в R,. Для установления структурного сходства и структурной иерархии понятий используются стратегии подтверждения сходства и разбиения на ступени.

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

Сформулируем основные этапы реализации системы приобретения знаний.

  1. Интервью для определения актуальной области, в которой происходит процесс решения интересующей проблемы, и расчленение ее на автономные области.
  2. Автоматизированное интервью для выявления и формирования декларативной модели предметной области.
  3. Протокольный анализ к выявленным на предыдущем этапе понятиям и отношениям предметной области для пополнения модели процедурными знаниями.
    (этапы 2 и 3 можно использовать попеременно до тех пор, пока модель не достигнет нужной полноты).
  4. Протокольный анализ для попонения декларативных знаний модели. б. Проверка полноты модели. Обычно протокольный анализ выявляет пустоты в модели. Имеется в виду случай, когда понятия, использованные в "мыслях вслух", недостаточно описаны. В этом случае интервью и протокольный анализ повторяются.

Формализация качественных знаний

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

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

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

При вводе в ЭВМ информации о лингвистических переменных и терм-множестве ее необходимо представить в форме, пригодной для работы на ЭВМ. Лингвистическая переменная задается набором из пяти компонентов: <Л, Т(А), U, <7, Af>, где Л-имя лингвистической переменной; Г (Л)-ее терм-множество;

U- область, на которой определены значения лингвистической переменной; 6 описывает операции по порождению производных значений лингвистической переменной на основе тех значений, которые входят в терм-множество. С помощью правил из О можно расширить число значений лингвистической переменной, т. е. расширить ее терм-множество. Каждому значению а лингвистической переменной Л соответствует нечеткое множество Ха, являющееся подмножеством V. По аналогии с формальными системами правила из G часто называют синтаксическими Наконец, компонент М образует набор семантических правил. С их помощью происходит отображение значений лингвистической переменной а в нечеткие множества Ха и выполняются обратные преобразования. Именно эти правила обеспечивают формализацию качественных утверждений экспертов при формировании проблемной области в памяти ИС.

На рис. 2Л показаны все компоненты, определяющие лингвистическую переменную <возраста>. В качестве терм-множества использовано множество, состоящее из трех значений: очень молодой (Ом), пожилой (п) и старый (с), задаваемых функциями принадлежности на области V, которую называют носителем лингвистических значений. В примере область V-года жизни от 0 до 150 лет, В качестве семантических правил выступают отображения, задаваемые функциями принадлежности 0<Цд(")<1 к нечетким множествам Лои" Хи, Хе. Как видно из рис. 2Л. человек, возраст которого равен 60 годам, принадлежит

к Хоы со значением 0 (т. в, человек в 60 лет не является очень молодым), к Ха со значением 0.8 и к Хс со значением 0.4.

Для перехода от качественных описаний к формализованным необходимо построить отображения, входящие в М, т. е. построить функции принадлежности, В таком виде подобная задача была исследована в [Блишун, 1987]

При получении от экспертов информации о виде функций принадлежности необходимо учитывать характер измерений (первичные и производные измерения) и тип шкалы, на которую проецируются измерения и на которой будут определяться функции принадлежности [Глотов и др.. 1976]. На этой шкале задается вид допустимых операторов и операций, т. е. некоторая алгебра для функций принадлежности. Кроме того, следует различать характеристики, которые можно измерять непосредственно и характеристики, которые являются качественными и требуют попарного сравнения объектов, обладающих этими характеристиками" чтобы определить их отношение к исследуемому понятию.

Можно выделить две группы методов построения функций принадлежности: прямые и косвенные. В прямых методах эксперт непосредственно задает правила определения значений функции принадлежности lia(u). Эти значения согласуются с его предпочтениями на множестве объектов следующим образом: для любых Ki, и 2 s U имеет место Ио(УО<Ио(и2) тогда и только тогда, когда йд предпочтительнее и\, т. е, в большей степени определяется понятием а; для любых уь u^eU имеет место Ца(1)=Ца(2) тогда и только тогда, когда Нч и и не различаются по отношению к понятию а. К прямым методам относится непосредственное задание функции принадлежности таблицей, формулой или примером [Zadeh, 1975; Ragade et aL, 1977; Thoie et a.. 1979].

В косвенных методах значения функции принадлежности выбираются таким образом, чтобы удовлетворялись заранее сформулированные условия. Экспертная информация является только исходной для дальнейшей обработки. Дополнительные условия могут налагаться как на вид получаемой информации, так и на процедуру обработки. Примерами дополнительных условий могут служить следующие: функция принадлежности должна отражать близость к заранее выделенному эталону, объекты множества являются точками в параметрическом пространстве [Scala, 1978]; результатом процедуры обработки должна быть функция принадлежности, удовлетворяющая условиям интервальной шкалы [Жуковин и др.. 1983]; при попарном сравнении объектов, если один объект оценивается в k раз сильнее, чем другой то второй объект оценивается в \/k раз сильнее, чем первый объект [Saaty, 1974]. и т. д.

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

В этом случае удобно непосредственное задание функции принадлежности. К прямым методам можно отнести методы, основанные на вероятностной трактовке функций принадлежности: а(и)==Р(а/и), т, е. вероятность того, что объект ueU будет принадлежать к множеству, которое характеризует понятием Так как люди часто искажают оценки, например сдвигают их в направлении концов оценочной шкалы [Thole et al., 1979]. то прямые измерения, основанные на непосредственном определении значений функции принадлежности, могут быть использованы только в том случае, когда такие искажения незначительны или маловероятны. Косвенные методы более трудоемки, чем прямые, но обладают стойкостью к искажениям в ответе. Результатом применения косвенных методов является интервальная шкала. В [Thole et al.. 1979] выдвигается для косвенных методов "условие безоговорочного экстремума": при определении степени принадлежности множество исследуемых объектов должно содержать по крайней мере два объекта, численные представления которых на интервале [0. 1] - О и 1 соответственно.

Функции принадлежности могут отражать мнение как некоторой группы экспертов, так и одного уникального эксперта. Комбинируя возможные дэа метода построения функций принадлежности с двумя типами экспертов (коллек-тивным и уникальным), можно получить четыре типа экспертизы [Блишун, 1988]

Пример формализации качественных знаний

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

Отображение любой ситуации на единичный интервал происходит таким образом, что точка интервала характеризует степень проявления некоторого свойства (0 соответствует отсутствию свойства, 1-интересующему нас максимальному проявлению свойства). При построений функции принадлежности используется модель измерений, которая определяется двумя параметрами: типом шкалы принадлежности, на которую отображается информация от эксперта" и типом измерения (прямой или косвенный). Шкала называется фундаментальной, если она допускает прямое взаимодействие множества U и того нечеткого свойства, которое нас интересует. Такая шкала дает возможность прямого измерения субъективного восприятия нечетких множеств на U со свойствами понятия а [Yager, 1982; Norwich et aL, 1984]. В табл. 2.1 приведены наиболее часто встречающиеся типы шкал и связанные с ними аксиомы.

Процесс формализации знаний, полученных у эксперта, состоит из следующих шагов: выбор метода измерения нечеткости, получение исходных данных посредством опроса эксперта, реализация алгоритма построения функции принадлежности. Известные методы формализации нечеткости систематизированы в табл. 2.2. В процессе реализации метода используются следующие характеристики: тип метода измерения (П - прямой, К - косвенный); интерпретация принадлежности (ВЧ-вероятность частотная, ВС-вероятность субъективная, В - возможность, Д - детерминированная); процедура получения исходных данных (ОФ - определение функции принадлежности в виде формул, 03-назначение значений принадлежности" ОДН-оценивание типа "да-нет"; ОПО- оценивание пар объектов; Р-ранжирование, РП-ранжирование пар объектов, ПС-попарное сравнение); измерений (Ф-фундаментальное, П-производное)'. тип шкалы (Н-номинальная" П-порядковая, И-интервальная, О- отношений, А - абсолютная),

Приведем пример измерения нечеткости. Множество оценок сходства приведено в табл. 2.3. В [Горячев и др., 1984] предполагается, что при оценке сходства используются числовые значения из табл. 2.3. Процедура формирования значений функции принадлежности следующая: I) фиксация понятия "Сходство";

2) ранжирование пар оценок сходства из табл. 2.3 по сходству в парах (чем больше сходство, тем меньше ранг); матрица сравнения пар оценок сходства приводится в табл. 2.4, 2 5 соответственно в строчной и матричной форме.

Литература

  1. Логический подход к искусственному интеллекту. / Под ред. Гаврилова Г.П. - М.: Мир,1990.
  2. Эндрю А. Искусственный интеллект / Под ред. Поспелова Д.А. - М.: Мир, 1985.
  3. Internet.


Системы понимания естественного языка

На главную страницу

Лекция 10: Системы понимания естественного языка

  1. Введение
  2. Предпосылки возникновения систем понимания естественного языка
  3. Понимание в диалоге
  4. Примеры системы обработки естественного языка
  5. Методы озвучивания речи
  6. Наиболее распространенные системы синтеза речи
  7. Речевой вывод информации
  8. Автоматический компьютерный синтез речи по тексту
    • Методы синтеза речи
    • Обобщенная функциональная структура синтезатора
    • Модуль лингвистической обработки
    • Лингвистический анализ
    • Формирование просодических характеристик
  9. Cинтезатор русской речи
    • Язык формальной записи правил синтеза
    • Интонационное обеспечение
    • Аллофонная база данных
    • Лингвистический анализ
    • Инструментарий синтеза русской речи
  10. Система распознавания речи
    • Акустическая модель
    • Лингвистическая модель
  11. Классификация систем распознавания речи
  12. Заключение
  13. Литература

Введение

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

Предпосылки возникновения систем понимания естественного языка

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

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

Понимание в диалоге

Как бы то ни было, продолжатся поиски такого интерфейса, который устроил бы всех. На эту роль сейчас претендует интерфейс речевой. Собственно говоря, это как раз то, к чему человечество всегда стремилось в общении с компьютером. Еще в эпоху перфокарт в научно-фантастических романах человек с компьютером именно разговаривал, как с равным себе. Тогда же, в эпоху перфокарт, или даже ранее, были предприняты первые шаги по реализации речевого интерфейса. Работы в этом направлении велись еще в то время, когда о графическом интерфейсе никто даже и не помышлял. За сравнительно короткий период был выработан исчерпывающий теоретический базис, и практические достижения обуславливались только производительностью компьютерной техники.Исследователи недалеко продвинулись за прошедшие десятки лет, что заставляет некоторых специалистов крайне скептически относиться к самой возможности реализации речевого интерфейса в ближайшем будущем. Другие считают, что задача уже практически решена. Впрочем, все зависит от того, что следует считать решением этой задачи.Построение речевого интерфейса распадается на три составляющие.

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

Пока окончательное решение существует только для третьей.По сути, синтез речи - это чисто математическая задача, которая в настоящее время решена на довольно хорошем уровне. И в ближайшее время, скорее всего, будет совершенствоваться только ее техническая реализация. Уже есть разного рода программы для чтения вслух текстовых файлов, озвучкой диалоговых окон. пунктов меню и могу засвидетельствовать, что с генерацией разборчивых текстовых сообщений они справляются без проблем.Препятствием для окончательного решения первой задачи служит то, что никто до сих пор толком не знает, каким образом можно расчленить нашу речь, чтобы извлечь из нее составляющие, в которых содержится смысл. В том звуковом потоке, который мы выдаем при разговоре, нельзя различить ни отдельных букв, ни слогов: даже, казалось бы, одинаковые буквы и слоги в разных словах на спектрограммах выглядят по-разному. Тем не менее многие фирмы уже имеют свои методики (увы, тщательно скрываемые), позволяющие худо-бедно решить эту задачу. Во всяком случае, после предварительной тренировки современные системы распознавания речи работают довольно сносно и делают ошибок не больше, чем делали оптические системы распознавания печатных символов лет пять-семь назад.Что касается второй задачи, то она, по мнению большинства специалистов, не может быть решена без помощи систем искусственного интеллекта. Большие надежды есть на появление так называемых квантовых компьютеров. Если же подобные устройства появятся, это будет означать качественный переворот в вычислительных технологиях.Поэтому пока удел речевого интерфейса - всего лишь дублирование голосом команд, которые могут быть введены с клавиатуры или при помощи мыши. А здесь его преимущества сомнительны.Впрочем, есть одна область, которая дли многих может оказаться очень привлекательной.Это речевой ввод текстов в компьютер. Действительно, чем стучать по клавиатуре, гораздо удобнее продиктовать все компьютеру, чтобы он записал услышанное в текстовый файл. Здесь вовсе не требуется, чтобы компьютер осмысливал услышанное, а задача перевода речи в текст более или менее решена. Недаром большинство выпускаемых ныне программ "речевого интерфейса" ориентированы именно на ввод речи.

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

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

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

Становление современной компьютерной индустрии проходило под флагом графического интерфейса, альтернативы которому в круге задач, решаемых сегодня компьютерами, не существует. Массовые приложения: САПР, офисные и издательские пакеты, СУБД составляют основной объем интеллектуальной начинки компьютеров, оставляя в их нынешнем виде очень мало места для применения альтернативных моделей пользовательского интерфейса, в том числе и речевого.

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

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

Для объективной оценки прогресса технологии распознавания речи сравните характеристики систем, реализованных в рамках проекта к 1976 году и систем, продвигаемых на рынок в настоящее время. Возникает два вопроса. Почему не нашли достойного применения разработки двадцатилетней давности и почему за такой продолжительный период не произошло видимого качественного сдвига в характеристиках конкретных систем? Ответ на I первый вопрос частично изложен выше: основная проблема-в области применения. Можно добавить. что вопреки настойчиво навязываемому сегодня в маркетинговых целях (в частности, для про- ' движения процессоров ММХ) мнению, высокие требования данной технологии к вычислительным ресурсам не являлись основным препятствиям к ее широкому внедрению. Возникновение схожих проблем у разработчиков графических систем привело к созданию и массовому применению графических аппаратных ускорителей,а не отказу от оконного интерфейса .При этом разрабатываемые peчевые адаптеры не превосходят по себестоимости графических.Ответ на второй вопрос напрямую связан с первым. Технология, не находящая применения, не может себя прокормить и обеспечить свой рост. Кроме того, вполне возможно, что ориентация большинства исследовательских центров на увеличение распознаваемого словаря является ошибочной как с точки зрения применимости, так и с точки зрения научной перспективности. Еще в 1969 году в своем знаменитом письме редактору журнала Акустического общества Америки Дж. Пиес, сотрудник фирмы Bell Laboratories,указал на отсутствие явного прогресса в то время и возможности такого прогресса технологии распознавания речи в ближайшем будущем в связи с неспособностью компьютеров анализировать синтаксическую, семантическую и прагматическую информацию, содержащуюся в высказывании. Имеющийся барьер может быть преодолен только с развитием систем искусственного интеллекта- направлением, натолкнувшимся в 70-х на барьер сложности и находящемся в настоящее время практически в полном забвении. Трудно надеяться на дальнейшее улучшение характеристик устройств речевого ввода, учитывая, что уже в 70-х годах их способность распознавать звуки речи превосходила человеческую. Данный факт был подтвержден серией экспериментов по сравнению уверенности распознавания человеком и компьютером слов иностранного языка и бессмысленных цепочек звуков. При отсутствии возможности подключения прагматических (смысловых), семантических и других анализаторов человек явно проигрывает.

Для иллюстрации приведенных выше, возможно, несколько спорных утверждений рассмотрим перспективу и основные проблемы применения систем речевого ввода текстов, особенно активно продвигаемых в последнее время.Для сравнения: спонтанная речь произносится со средней скоростью 2,5 слов в секунду, профессиональная машинопись - 2 слова в секунду, непрофессиональная -0,4. Таким образом, на первый взгляд, речевой ввод имеет значительное превосходство по производительности. Однако оценка средней скорости диктовки в реальных условиях снижается до 0,слова в секунду в связи с необходимостью четкого произнесения слов при речевом вводе и достаточно высоким процентом ошибок распознавания, нуждающихся в корректировке.Речевой интерфейс естественен для человека и обеспечивает дополнительное удобство при наборе текстов. Однако даже профессионального диктора может не обрадовать перспектива в течение нескольких часов диктовать малопонятливому и немому (к этому еще вернемся) компьютеру. Кроме того, имеющийся опыт эксплуатации подобных систем свидетельствуете высокой вероятности заболевания голосовых связок операторов, что связано с неизбежной при диктовке компьютеру монотонностью речи.

Часто к достоинствам речевого ввода текста относят отсутствие необходимости в предварительном обучении. Однако одно из самых слабых мест современных систем распознавания речи - чувствительность к четкости произношения - приводит к потере этого, казалось бы, очевидного преимущества, Печатать на клавиатуре оператор учится в среднем 1-2 месяца. Постановка правильного произношения может занять несколько лет. Кроме того, дополнительное напряжение -следствие сознательных и подсознательных усилий по достижению более высокой распознаваемости - совсем не способствует сохранению нормального режима работы речевого аппа-рата оператора и значительно увеличивает риск появления специфических заболеваний.Существует и еще одно неприятное ограничение применимости, сознательно не упоминаемое, на мой взгляд, создателями систем речевого ввода. Оператор, взаимодействующий с компьютером через речевой интерфейс, вынужден работать в звукоизолированном отдельном помещении либо пользоваться звукоизолирующим шлемом. Иначе он будет мешать работе своих соседей по офису, которые, в свою очередь, создавая дополнительный шумовой фон будут значительно затруднять работу речевого распознавателя, Таким образом, речевой интерфейс вступает в явное противоречие с современной организационной структурой предприятий, ориентированных на коллективный труд. Ситуация несколько смягчается с развитием удаленных форм трудовой деятельности, однако еще достаточно долго самая естественная для человека производительная и потенциально массовая форма пользовательского интерфейса обречена на узкий круг применения.

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

Примеры системы обработки естественного языка

Самый успешный на сегодня проект коммерческого применения распознавания речи - телефонная сеть фирмы AT&. Клиент может запросить одну из пяти категорий услуг, используя любые слова. Он говорит до тех пор, пока в его высказывании встретится одно из пяти ключевых слов. Эта система в настоящее время обслуживает около миллиарда звонков в год.Данный вывод находится в противоречии с устоявшимися широко распространенными стереотипами и ожиданиями.Несмотря на то, что одним из наиболее перспективных направлений для внедрения систем распознавания речи может стать сфера компьютерных игр, узкоспециализированных реабилитационных программ для инвалидов, тепефонных и информационных систем, ведущие разработчики речевого распознавания наращивают усилия по достижению универсализации и увеличения объемов словаря даже в ущерб сокращению процедуры предварительной настройки на диктора. А между тем именно эти приложения представляют очень низкие требования к объему распознаваемого словаря наряду с жесткими ограничения, налагаемыми на предварительную настройку.Более того распознавание спонтанной слитной речи практически топчется на месте с ^ 70-х годовв силу неспособности компьютера эффективно анализировать неакустические характеристики речи.Даже Билл Гейтс, являющий собой смысле идеал прагматизма, оказался не свободен от исторически сложившихся стереотипов. Начав в 95-96 году с разработки собственной универсальной системы распознавания речи провозгласил очередную эру повсеместного внедрения речевого интерфейса. Средства речевого планируется включить в стандартную поставку новой версии - чисто офисной операционной системы. При этом руководитель Microsoft упорно повторяет фразу о том, что скоро можно будет забыть о клавиатуре и мыши. Вероятно, он планирует продавать вместе с коробкой Windows NT акустические шлемы вроде тех, которые используют военные летчики и пилоты "Формулы 1". Кроме того, неужели Microsoft в ближайшем будущем npeкратит выпycк Word, Excel и т. д.? Управлять графическими объектами экрана голосом, не имея возможности помочь руками, более чем затруднительно.

Говоря о речевом интерфейсе, часто делают упор на распознавание речи, забывая о другой его стороне- речевом синтезе. Заглавную роль в этом перекосе сыграло бурное развитие в последнее время систем, ориентированных на события ,в значительной степени подавляющих отношение к компьютеру как активной стороне диалога.Еще относительно недавно (лет тридцать назад) подсистемы распознавания и синтеза речи рассматривались как части единого комплекса речевого интерфейса. Однако интерес к синтезу пропал достаточно быстро. Во-первых, разработчики не встретили даже десятой доли сложностей, с которыми они столкнулись при создании систем распознавания. Во-вторых, в отличие от распознавания синтез речи не демонстрирует значительных преимуществ перед другими средствами вывода информации из компьютера. Практически вся его ценность заключается в дополнении речевого ввода.Для человека естественным и привычным является именно диалог, а не монолог. Как следствие недооценки необходимости речевого ответа появляется повышенная утомляемость операторов, монотонность речи и ограниченность применимости речевого интерфейса. Чем может помочь слепому компьютер, оснащенный распознавателем речи, если он лишен устройства обратной не визуальной связи?

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

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

Методы озвучивания речи

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

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

Компилятивный синтез осуществляется путем склейки нужных единиц компиляции из имеющегося инвентаря. На этом принципе построено множество систем, использующих разные типы единиц и различные методы составления инвентаря. В таких системах необходимо применять обработку сигнала для приведения частоты основного тона, энергии и длительности единиц к тем, которыми должна характеризоваться синтезируемая речь. Кроме того, требуется, чтобы алгоритм обработки сигнала сглаживал разрывы в формантной (и спектральной в целом) структуре на границах сегментов. В системах компилятивного синтеза применяются два разных типа алгоритмов обработки сигнала: LР (сокр. англ. Linear Рreduction - линейное предсказание) и РSOLA (сокр. англ. Рitch Sуnchronous Оvеrlap аnd Аdd). LP-синтез основан в значительной степени на акустической теории речеобразования, в отличие от РSOLA-синтеза, который действует путем простого разбиения звуковой волны, составляющей единицу компиляции, на временные окна и их преобразования. Алгоритмы РSOLA позволяют добиваться хорошего сохранения естественности звучания при модификации исходной звуковой волны.

Наиболее распространенные системы синтеза речи

Наиболее распространенными системами синтеза речи на сегодня, очевидно, являются системы, поставляемые в комплекте со звуковыми платами. Если ваш компьютер оснащен какой-либо из них, существует значительная вероятность того, что на нем установлена система синтеза речи - увы, не русской, а английской речи, точнее, ее американского варианта. К большинству оригинальных звуковых плат Sound Blaster прилагается система Сreative Техt-Аssist, а вместе со звуковыми картами других производителей часто поставляется программа Моnо1оgue компании First Byte.

TextAssist представляет собой реализацию формантного синтезатора по правилам и базируется на системе DECTalk, разработанной корпорацией Digital Eguipment при участии известного американского фонетиста Денниса Клана (к сожалению, рано ушедшего из жизни). DECTalk до сих пор остается своего рода стандартом качества для синтеза речи американского варианта английского. Компания Сrеаtive Technologies предлагает разработчикам использовать ТехtАssist в своих программах с помощью специального ТехtАssistАpi(ААРI). Поддерживаемые операционные системы - МS Windows и Windows 95; для Windws NT также существует версия системы DЕСТаlk, изначально создававшейся для Digital Units. Новая версия ТехtАssist, объявленная фирмой Аssotiative Computing, inс. и разработанная с использованием технологий DЕСTа1k и Сrеаtivе, является в то же время многоязычной системой синтеза, поддерживая английский, немецкий, испанский и французский языки. Это обеспечивается прежде всего использованием соответствующих лингвистических модулей, разработчик которых - фирма Lеrnout& Наuspie Sреесh Рrоducts, признанный лидер в поддержке многоязычных речевых технологий. В новой версии будет встроенный редактор словаря, а также специализированное устройство ТехtRеаdеr с кнопочным управлением работой синтезатора в разных режимах чтения текста.

Программа Моnоlоguе, предназначенная для озвучивания текста, находящегося в буфере обмена МS Windows, использует систему РrоVоiсе. РrоVоiсе - компилятивный синтезатор с использованием оптимального выбора режима компрессии речи и сохранения пограничных участков между звуками, разновидность ТD-РS0LА. Рассчитан на американский и британский английский, немецкий, французский, латино-американскую разновидность испанского и итальянский языки. Инвентарь сегментов компиляции - смешанной размерности: сегменты - фонемы или аллофоны. Компания First Вуtе позиционирует систему РrоVоicе и программные продукты, основанные на ней, как приложения с низким потреблением процессорного времени. FirstByte также предлагает рассчитанную на мощные компьютеры систему артикуляторного синтеза РrimoVox для использования в приложениях телефонии. Для разработчиков: Моnо1оguе Win32 поддерживает спецификацию Мicrosoft SAPI.

Мода на свободно распространяемые продукты не миновала и области приложений синтеза речи. МВR0LA- так называется система многоязычного синтеза, реализующая особый гибридный алгоритм компилятивного синтеза и работающая как под РС/ Windows 3.1, РС/Windows 95, так и под Sun4. Впрочем, система принимает на входе цепочку фонем, а не текст, и потому не является, строго говоря, системой синтеза речи по тексту. Формантный синтезатор Тru-Voicе фирмы Сеntigram Cоmmunication Соrporation(США) близок к описанным выше системам по архитектуре и предоставляемым возможностям, однако он поддерживает больше языков: американский английский, латино-американский, испанский, немецкий, французский, итальянский. Кроме того, в этот синтезатор включен специальный препроцессор, который обеспечивает быструю подготовку для чтения сообщений, получаемых по электронной почте, факсов и баз данных.

Речевой вывод информации

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

С точки зрения пользователя, наиболее разумное решение проблемы синтеза речи - это включение речевых функций (в перспективе - многоязычных, с возможностями перевода) в состав операционной системы. Точно так же, как мы пользуемся командой РRINT, мы будем применять команду ТАLК или SРЕАК. Такие команды появятся в меню общеупотребительных компьютерных приложений и в языках программирования. Компьютеры будут озвучивать навигацию по меню, читать (дублировать голосом) экранные сообщения, каталоги файлов, и т. д. Важное замечание: пользователь должен иметь достаточные возможности по настройке голоса компьютера, в частности, при желании, суметь выключить голос совсем.

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

Автоматический компьютерный синтез речи по тексту

Методы синтеза речи

Теперь, после оптимистического описания ближайшего будущего, давайте обратимся собственно к технологии синтеза речи. Рассмотрим какой-нибудь хотя бы минимально осмысленный текст. Текст состоит из слов, разделенных пробелами и знаками препинания. Произнесение слов зависит от их расположения в предложении, а интонация фразы - от знаков препинания. Более того, довольно часто и от типа применяемой грамматической конструкции: в ряде случаев при произнесении текста слышится явная пауза, хотя какие-либо знаки препинания отсутствуют. Наконец, произнесение зависит и от смысла слова! Сравните, например, выбор одного из вариантов "за 'мок" или " замо 'к" для одного и того же слова "замок".

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

Обобщенная функциональная структура синтезатора

Структура идеализированной системы автоматического синтеза речи состоит из нескольких блоков.

  • Определение языка текста
  • Нормализация текста
  • Лингвистический анализ:синтаксический,морфемный анализ и т.д.
  • Формирование просоидических характеристик
  • Фонемный транскриптор
  • Формирование управляющей информации
  • Получение звукового сигнала

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

Модуль лингвистической обработки

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

Лингвистический анализ

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

Кроме того, следует корректно рассматривать случаи графической омонимии: одна и та же последовательность буквенных символов в различных контекстах порой представляет два различных слова/словоформы и читается по-разному (ср. выше приведенный пример слова "замок"). Часто удается решить проблему неоднозначности такого рода путем грамматического анализа, однако иногда помогает только использование более широкой семантической информации.

Для языков с достаточно регулярными правилами чтения одним из продуктивных подходов к переводу слов в фонемы является система контекстных правил, переводящих каждую букву/буквосочетание в ту или иную фонему, то есть автоматический фонемный транскриптор. Однако чем больше в языке исключений из правил чтения, тем хуже работает этот метод. Стандартный способ улучшения произношения системы состоит в занесении нескольких тысяч наиболее употребительных исключений в словарь. Альтернативное подходу "слово-буква-фонема" решение предполагает морфемный анализ слова и перевод в фонемы морфов (то есть значимых частей слова: приставок, корней, суффиксов и окончаний). Однако в связи с разными пограничными явлениями на стыках морфов разложение на эти элементы представляет собой значительные трудности. В то же время для языков с богатой морфологией, например, для русского, словарь морфов был бы компактнее. Морфемный анализ удобен еще и потому, что с его помощью можно определять принадлежность слов к частям речи, что очень важно для грамматического анализа текста и задания его просодических характеристик. В английских системах синтеза морфемный анализ был реализован в системе МIТа1к, для которой процент ошибок транскриптора составляет 5%.

Особую проблему для данного этапа обработки текста образуют имена собственные.

Формирование просодических характеристик

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

Формирование просодических характеристик, необходимых для озвучивания текста, осуществляется тремя основными блоками, а именно: блоком расстановки синтагматических границ (паузы), блоком приписывания ритмических и акцентных характеристик (длительности и энергия), блоком приписывания тональных характеристик (частота основного тона). При расстановке синтагматических границ определяются части высказывания (синтагмы), внутри которых энергетические и тональные характеристики ведут себя единообразно и которые человек может произнести на одном дыхании. Если система не делает пауз на границах таких единиц, то возникает отрицательный эффект: слушающему кажется, что говорящий (в данном случае - система) задыхается. Помимо этого, расстановка синтагматических границ существенна и для фонемной транскрипции текста. Самое простое решение состоит в том, чтобы ставить границы там, где их диктует пунктуация. Для наиболее простых случаев, когда пунктуационные знаки отсутствуют, можно применить метод, основанный на использовании служебных слов. Именно эти методы используются в системах синтеза Рго-Sе-2000, Infovox- 5А-101 и DЕСTаLк, причем в последней просодически ориентированный словарь, помимо служебных слов, включает еще и глагольные формы.

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

Cинтезатор русской речи

В качестве примера рассмотрим разработку "Говорящая мышь" клуба голосовых технологий научного парка МГУ. (Известно, что в некоторых российских организациях и компаниях ведутся аналогичные разработки, однако подробных сведений в печати обнаружить не удалось.

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

Язык формальной записи правил синтеза

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

Интонационное обеспечение

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

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

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

Аллофонная база данных

Необходимый речевой материал был записан в следующем режиме оцифровки: частота дискретизации 22 кГц с разрядностью 16 бит.

В качестве базовых элементов компиляции выбраны аллофоны, оптимальный набор которых и представляет собой акустико-фонетическую базу синтеза. Инвентарь базовых единиц компиляции включает в себя 1200 элементов, который занимает около 7 Мбайт памяти. В большинстве случаев элементы компиляции представляют собой сегменты речевой волны фонемной размерности. Для получения необходимой исходной базы единиц компиляции был составлен специальный словарь,который содержит слова и словосочетания с аллофонами во всех учитываемых контекстах. В нем содержится 1130 словоупотреблений.

Лингвистический анализ

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

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

Готовый акустический сигнал преобразуется в формат данных, принятый для вывода звуковой информации. Используются два формата: WAV (Waveform Audio File Format), являющийся одним из основных, или VОХ (Voice File Format), широко используемый в компьютерной телефонии. Вывод также может осуществляться непосредственно на звуковую карту.

Инструментарий синтеза русской речи

Упоминавшийся выше инструментарий синтеза русской речи по тексту позволяет читать вслух смешанные русско-английские тексты. Инструментарий представляет собой набор динамических библиотек (DLL), в который входят модули русского и английского синтеза, словарь ударений русского языка, модуль правил произнесения английских слов. На вход инструментария подается слово или предложение, подлежащее произнесению, с выхода поступает звуковой файл в формате WAV или VOX, записываемый в память или на жесткий диск.

Cистема распознавания речи

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

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

Акустическая модель

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

Лингвистическая модель

Лингвистический блок подразделяется на следующие ярусы (слои, уровни); фонетический, фонологический, морфологический, лексический,синтаксический, семантический.Всего их шесть. За основу взят русский язык. Все ярусы суть априорная информация о структуре естественного языка, а, как известно, любая априорная информация об интересующем предмете увеличивает шансы принятия верного решения. На том стоит вся статистическая радиотехника. А естественный язык несет весьма сильно структурированную информацию, из чего, кстати, вытекает, что для каждого естественного языка может потребоваться своя уникальная лингвистическая модель (предвижу трудности с русификацией сложных систем распознавания речи). В соответствии с данной моделью на первом - фонетическом- уровне производится преобразование входного (для лингвистического блока) представления речи в последовательность фонем, как наименьших единиц языка. Считается, что в реальном речевом сигнале можно обнаружить лишь аллофоны - варианты фонем, зависящие от звукового окружения. Но сути это не меняет. Обратите внимание, что фонемы сотоварищи могут перекочевать в лингвистический блок. На следующем - фонологическом - уровне накладываются ограничения на комбинаторику фонем (аллофонов). Ограничение - это правило наизнанку, значит, опять есть полезная априорная информация: не все сочетания фонем (аллофонов) встречаются, а те, что встречаются, имеют различную вероятность появления, зависящую еще и от окружения. Для описания этой ситуации используется математический аппарат цепей Маркова. Далее, на морфологическом уровне оперируют со слогоподобными единицами речи более высокого уровня, чем фонема. Иногда они называются морфемами. Они накладывают ограничение уже на структуру слова, подчиняясь закономерностям моделируемого естественного языка. Лексический ярус охватывает слова и словоформы того или иного естественного языка, то есть словарь языка, так же внося важную априорную информацию о том, какие слова возможны для данного естественного языка. Семантика устанавливает соотношения между объектами действительности и словами, их обозначающими. Она является высшим уровнем языка. При помощи семантических отношений интеллект человека производит как бы сжатие речевого сообщения в систему образов, понятий, представляющих суть речевого сообщения. Отсюда следует вывод, что система должна быть "умной". Чем лучше у нее будет построена модель семантических связей, эквивалента "системы мысленных образов", тем больше вероятность правильно распознать речь.

Классификация систем распознавания речи

Классификация по назначению:

  • командные системы
  • системы диктовки текста

По потребительским качествам:

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

По механизмам функциониро-вания:

  • простейшие (корреляционные) детекторы
  • экспертные системы с различным способом формирования и обработки базы знаний
  • вероятностно-сетевые модели принятия решения, в том числе нейронные сети.

Заключение

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

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

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

Литература

  1. Компьютерра 08.12.97.p.26-43
  2. Ю.М.Смирнов. Интеллектуализация ЭВМ.Москва,Высшая школа,1989 г.
  3. Expert system saves 20 million L on pipeline management. C&I July, 1994, р.31.
  4. Р. Harmon. The Market for Intelligent Software Products. Intelligent Sopware Strategies 1992, v.8, n.2, рр.5-12.
  5. D.R Perley. Migrating to Open Systems: Taming he Tiger. McGraw-Hill, 1993, р.252.
  6. Р. Harmon. The AI Tools Market The Market for Intelligent Software Building Tools. Part I. Intelligent Softwane Strategies, 1994, v 10, n.2, pp.1-14.
  7. Р. Harmon. The market for intelligent software pnducts Intelligent Software Strategies, 1992, v.8, n.2, рр.5-12.
  8. B.R. Clements and F. Preto. Evaluating Commencial Real Time Expert System Software for Use in the Process Industries. C&I, 1993, рр. 107-114.
  9. В. Моorе et al. Questions and Answers about G2. 1993. Gensym Corporation. рр.26-28.
  10. B. Moore. Memorandum. 1993, April. Gensym Corparation.
  11. Р. Богатырев. "Этот странный придуманный мир". Компьютерра. c.30-33. 1996 год.


Системы машинного зрения

На главную страницу

Лекция 11: Системы машинного зрения

  1. Введение
  2. Основные принципы или целостность восприятия
  3. Распознавание символов
    • Шаблонные системы
    • Структурные системы
    • Признаковые системы
  4. Структурно-пятенный эталон
  5. Уроки машинного чтения от Cognitive Technologies
  6. Распознавание рукописных текстов
  7. Резюме

Введение

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

Компанией "Бит" была разработана специальная технология распознавания символов, которая получила название "Фонтанного преобразования" , а на ее основе - коммерческий продукт, получивший высокую оценку. Это система оптического распознавания Fine Reader. Сегодня на рынке представлена уже третья версия продукта, которая работает не только с текстом, но и с формами, таблицами, а разработчики уже колдуют над новой четвертой версией Fine Reader, которая будет распознавать не только печатный но и рукописный текст.

Основные принципы или целостность восприятия

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

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

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

В технических системах любое решение при распознавании текста принимается неоднозначно, а путем последовательного выдвижения и проверки гипотез и привлечения как знаний о самом исследуемом объекте, так и общего контекста. Целостное описание класса объектов восприятия отвечает двум условиям: во - первых, все объекты данного класса удовлетворяют этому описанию, а во- вторых, ни один объект другого класса не удовлетворяют ему. Например, класс изображений буквы "К" должен быть описан так, чтобы любое изображение буквы "К" в него попадало, а изображение всех других букв - нет. Такое описание обладает свойством отображаемости, то есть обеспечивает воспроизведение описываемых объектов: эталон буквы для системы OCR позволяет визуально воспроизвести букву, эталон слова для распознавания речи позволяет произнести слово, а описание структуры предложения в синтаксическом анализаторе позволяет синтезировать правильное предложение. С практической точки зрения отображаемость играет огромную роль, поскольку позволяет эффективно контролировать качество описаний.

Существует два вида целостного описания: шаблонное и структурное.

В первом случае описание представляет собой изображение в растровом или векторном представлении, и задан класс преобразований (например, повтор, масштабирование и пр.).

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

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

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

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

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

Ныне одним из лидеров в области генетического программирования является группа исследователей из Стэндфордского университета (Stanford University), работающая под руководством профессора Джона Коза. Генетическое программирование вдохнуло новую жизнь в хорошенько уже подзабытый язык LISP (List Processing), который создавался группой Джона Маккарти (того самого, кто в 60-е годы ввел в наш обиход термин "искусственный интеллект") как раз для обработки списков и функционального программирования. Кстати, именно этот язык в США был и остается одним из наиболее распространенных языков программирования для задач искусственного интеллекта.

Распознавание символов

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

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

Шаблонные системы

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

Структурные системы

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

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

Признаковые системы

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

Структурно-пятенный эталон

Фонтанное преобразование совмещает в себе достоинства шаблонной и структурной систем и, по нашему мнению, позволяет избежать недостатков, присущих каждой из них по отдельности. В основе этой технологии лежит использование структурно-пятенного эталона. Он позволяет представить изображения в виде набора пятен, связанных между собой n-арными отношениями, задающими структуру символа. Эти отношения (то есть расположение пятен друг относительно друга) образуют структурные элементы, составляющие символ. Так, например, отрезок - это один тип n-арных отношений между пятнами, эллипс - другой, дуга - третий. Другие отношения задают пространственное расположение образующих символ элементов.

В эталоне задаются:

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

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

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

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

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

Конкретизирующие параметры используются также для вычисления <качества> конкретного структурного элемента изображения и <качества> выполнения данного отношения.

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

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

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

Уроки машинного чтения от Cognitive Technologies

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

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

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

В CuneiForm'96 мы впервые применили алгоритмы самообучения (или адаптивного распознавания). Принцип их работы состоит в следующем. В каждом тексте присутствуют четко и нечетко пропечатанные символы. Если после того как система распознала текст (как это делает обычная система, например предыдущая версия OCR CuneiForm 2.95), выясняется, что точность оказалась ниже пороговой, производится дораспознавание текста на основе шрифта, который генерируется системой по хорошо пропечатанным символам. Здесь разработчики соединили достоинства двух типов систем распознавания: омнии мультишрифтовые. Напомним, что первые позволяют распознавать любые шрифты без дополнительного обучения, вторые же более устойчивы при распознавании низкокачественных текстов. Результаты применения Cunei-Form'96 показали, что использование самообучающихся алгоритмов позволяет поднять точность распознавания низкокачественных текстов в четыре-пять раз! Но главное, пожалуй, в том, что самообучающиеся системы обладают гораздо большим потенциалом повышения точности распознавания.

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

Сегодня наряду с задачами повышения точности распознавания на передний план выходят вопросы расширения сфер применения OCR-технологий, соединения технологий распознавания с архивными системами. Иными словами, мы переходим от монопрограммы, выполняющей функции ввода текста, к автоматизированным комплексам, решающим задачи клиента в области документооборота. Вот уже около полугода CuneiForm поставляется в комплекте с сервером распознавания CuneiForm OCR Server, предназначенным для коллективного ввода данных в организациях, а электронный архив <Евфрат>, включающий модуль распознавания, за короткое время приобрел большую популярность.

С таким прицелом создавался и комплект CuneiForm'96i Professional, существенно изменивший представления о системах распознавания в целом.

Распознавание рукописных текстов

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

И все же сегодня мы можем признать, что основные этапы разработки технологии распознавания рукописных (отдельные символы, написанные от руки) символов уже пройдены. В арсенале Cognitive Technologies имеются технологии распознавания всех основных типов текстов: стилизованных цифр, печатных символов и <рукопечатных> символов. Но технологии ввода <рукопечатных> символов потребуется еще пройти стадию адаптации, после чего можно будет заявить, что инструментарий для потокового ввода документов в архивы действительно реализован полностью.

Резюме

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

С появлением сетевых версий систем сканирования (режим потокового сканирования OCR CuneiForm) и распознавания (сервер распознавания CuneiForm OCR Server) документов нашей компании уже удалось реализовать некоторые преимущества коллективного использования таких технологий в организациях разного масштаба. По этой причине, с нашей точки зрения, актуальным был бы разговор о комплексном решении компаниями проблемы автоматизации работы с документами в организациях самого различного ранга. Что касается Cognitive Technologies, то представляемый ею электронный архив <Евфрат> (система включает в себя возможность ввода документов с помощью OCR CuneiForm), новые утилиты, встроенные в OCR CuneiForm'96, и технологии, используемые при реализации крупных проектов, продолжают линию компании, направленную на расширение применения систем ввода информации и разработку технологий автоматизации работы с документами.


Тенденции развития систем искусственного интеллекта

На главную страницу

Лекция 12: Тенденции развития систем искусственного интеллекта

  1. Введение
  2. Состояние и тенденции развития искусственного интеллекта
  3. Успехи систем искусственного интеллекта и их причины
  4. Экспертные системы реального времени - основное направление искусственного интеллекта
  5. Основные производители
  6. Архитектура экспертной системы реального времени
  7. Жизненный цикл приложения
    • Разработка прототипа приложения
    • Расширение прототипа до приложения
    • Тестирование приложения на ниличие ошибок
    • Тестирование логики приложения и ограничений (по времени и памяти)
    • Сопровождение приложения
  8. Основные компоненты
  9. База знаний
    • Сущности и иерархия классов
    • Иерархия модулей и рабочих пространств
    • Структуры данных
    • Выполняемые утверждения
  10. Машина вывода, подсистема моделирования и планировщик
  11. Заключение
  12. Литература

Введение

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

Бернард Шоу.

Парадоксальное высказывание Бернарда Шоу имеет непосредственное отношение к тексту статьи. В самом деле, почему человек так стремится поработить себя машинами? На сколько велика их власть над людьми? Неужели весь прогресс человечества в том только и заключается, чтобы построить такой мир, в котором сам человек станет звеном избыточным, а потом неизбежно исчезнет?

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

Искусственный интеллект вообще и экспертные системы в частности прошли долгий и тернистый путь: первые увлечения (1960 год), лженаука (1960-65), успехи при решении головоломок и игр (1965-1975), разочарование при решении практических задач (1970-1985), первые успехи при решении ряда практических задач (1962-1992), массовое коммерческое использование при решении практических задач (1993-1995). Но основу коммерческого успеха по праву составляют экспертные системы и, в первую очередь, экспертные системы реального времени. Именно они позволили искусственному интеллекту перейти от игр и головоломок к массовому использованию при решении практически значимых задач.

Состояние и тенденции развития искусственного интеллекта

Программные средства, базирующиеся на технологии и методах искусственного интеллекта, получили значительное распространение в мире. Их важность, и, в первую очередь, экспертных систем и нейронных сетей, состоит в том, что данные технологии существенно расширяют круг практически значимых задач, которые можно решать на компьютерах, и их решение приносит значительный экономический эффект. В то же время, технология экспертных систем является важнейшим средством в решении глобальных проблем традиционного программирования: длительность и, следовательно, высокая стоимость разработки приложений; высокая стоимость сопровождения сложных систем; повторная используемость программ и т.п. Кроме того, объединение технологий экспертных систем и нейронных сетей с технологией традиционного программирования добавляет новые качества к коммерческим продуктам за счет обеспечения динамической модификации приложений пользователем, а не программистом, большей "прозрачности" приложения (например, знания хранятся на ограниченном естественном языке, что не требует комментариев к ним, упрощает обучение и сопровождение), лучших графических средств, пользовательского интерфейса и взаимодействия. По мнению специалистов [1], в недалекой перспективе экспертные системы будут играть ведущую роль во всех фазах проектирования, разработки, производства, распределения, продажи, поддержки и оказания услуг. Их технология, получив коммерческое распространение, обеспечит революционный прорыв в интеграции приложений из готовых интеллектуально-взаимодействующих модулей. Коммерческий рынок продуктов искусственного интеллекта в мире в 1993 году оценивался примерно в 0,9 млрд. долларов; из них 600 млн. приходится на долю США [2]. Выделяют несколько основных направлений этого рынка: 1) экспертные системы; теперь их часто обозначают еще одним термином - "системы, основанные на знаниях"; 2) нейронные сети и "размытые" (fuzzy) логики; 3) естественно-языковые системы. В США в 1993 году рынок между этими направлениями распределился так [2]: экспертные системы - 62%, нейронные сети - 26%, естественно-языковые системы - 12%. Рынок этот можно разделить и иначе: на системы искусственного интеллекта (приложения) и инструментальные средства, предназначенные для автоматизации всех этапов существования приложения. В 1993 году в общем объеме рынка США доля приложений составила примерно две, а доля инструментария - примерно одну треть [2].

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

В том, что касается автономных (интеллектуальных) агентов, хотелось бы отметить один весьма прагматический проект, который сейчас ведется под руководством профессора Генри Либермана в Media-лаборатории MIT (MIT Media Lab). Речь идет об агентах, отвечающих за автоматическое генерирование технической документации. Для решения этой задачи немало сделал в свое время академик Андрей Петрович Ершов, сформулировавший понятие деловой прозы как четко определенного подмножества естественного языка, которое может быть использовано, в частности, для синтеза технической документации (это одно из самых узких мест в любом производстве). Группа под руководством профессора Либермана исследует возможности нового подхода к решению этой проблемы, теперь уже на основе автономных агентов.

Следующее направление в области искусственной жизни - генетическое программирование (genetic programming) - является попыткой использовать метафору генной инженерии для описания различных алгоритмов. Строки (string) искусственной "генетической" системы аналогичны хромосомам в биологических системах. Законченный набор строк называется структурой (structure). Структуры декодируются в набор параметров, альтернативы решений или точку в пространстве решений. Строки состоят из характеристик, или детекторов, которые могут принимать различные значения. Детекторы могут размещаться на разных позициях в строке. Все это сделано по аналогии с реальным миром. В природных системах полный генетический пакет называется генотипом. Организм, который образуется при взаимодействии генотипа с окружающей средой, носит название фенотипа. Хромосомы состоят из генов, которые могут принимать разные значения. (Например, ген цвета для глаза животного может иметь значение "зеленый" и позицию 10).

В генетических алгоритмах роль основных строительных блоков играют строки фиксированной длины, тогда как в генетическом программировании эти строки разворачиваются в деревья, столь знакомые специалистам в области трансляции. Например, выражение a+b*c выглядит так:

Ныне одним из лидеров в области генетического программирования является группа исследователей из Стэндфордского университета (Stanford University), работающая под руководством профессора Джона Коза. Генетическое программирование вдохнуло новую жизнь в хорошенько уже подзабытый язык LISP (List Processing), который создавался группой Джона Маккарти (того самого, кто в 60-е годы ввел в наш обиход термин "искусственный интеллект") как раз для обработки списков и функционального программирования. Кстати, именно этот язык в США был и остается одним из наиболее распространенных языков программирования для задач искусственного интеллекта.

Успехи систем искусственного интеллекта и их причины

Использование экспертных систем и нейронных сетей приносит значительный экономический эффект. Так, например: - American Express [1] сократила свои потери на 27 млн. долларов в год благодаря экспертной системе, определяющей целесообразность выдачи или отказа в кредите той или иной фирме; - DEC ежегодно экономит [1] 70 млн. долларов в год благодаря системе XCON/XSEL, которая по заказу покупателя составляет конфигурацию вычислительной системы VAX. Ее использование сократило число ошибок от 30% до 1%; - Sira сократила затраты на строительство трубопровода в Австралии на 40 млн. долларов [3] за счет управляющей трубопроводом экспертной системы, реализованной на базе описываемой ниже системы G2. Коммерческие успехи к экспертным системам и нейронным сетям пришли не сразу. На протяжении ряда лет (с 1960-х годов) успехи касались в основном исследовательских разработок, демонстрировавших пригодность систем искусственного интеллекта для практического использования. Начиная примерно с 1985 (а в массовом масштабе, вероятно, с 1988-1990 годов), в первую очередь, экспертные системы, а в последние два года и нейронные сети стали активно использоваться в реальных приложениях. Причины, приведшие системы искусственного интеллекта к коммерческому успеху, следующие: 1. Специализация. Переход от разработки инструментальных средств общего назначения к проблемно/предметно специализированным средствам [4], что обеспечивает сокращение сроков разработки приложений, увеличивает эффективность использования инструментария, упрощает и ускоряет работу эксперта, позволяет повторно использовать информационное и программное обеспечение (объекты, классы, правила, процедуры). 2. Использование языков традиционного программирования и рабочих станций. Переход от систем, основанных на языках искусственного интеллекта (Lisp, Prolog и т.п.), к языкам традиционного программирования (С, С++ и т.п.) упростил "интегрированность" и снизил требования приложений к быстродействию и емкости памяти. Использование рабочих станций вместо ПК резко увеличило круг возможных приложений методов искусственного интеллекта. 3. Интегрированность. Разработаны инструментальные средства искусственного интеллекта, легко интегрирующиеся с другими информационными технологиями и средствами (с CASE, СУБД, контроллерами, концентраторами данных и т.п.). 4. Открытость и переносимость. Разработки ведутся с соблюдением стандартов, обеспечивающих данные характеристики [5]. 5. Архитектура клиент/сервер. Разработка распределенной информационной системы в данной архитектуре позволяет снизить стоимость оборудования, используемого в приложении, децентрализовать приложения, повысить надежность и общую производительность, поскольку сокращается объем информации, пересылаемой между ЭВМ, и каждый модуль приложения выполняется на адекватном оборудовании. Перечисленные причины могут рассматриваться как общие требования к инструментальным средствам создания систем искусственного интеллекта. Из пяти факторов, обеспечивших их успех в передовых странах, в России, пожалуй, полностью не реализованы четыре с половиной (в некоторых отечественных системах осуществлен переход к языкам традиционного программирования, однако они, как правило, ориентированы среду на MS-DOS, а не ОС UNIX или Windows NT. Кроме того, в России и СНГ в ряде направлений исследования практически не ведутся, и, следовательно, в этих направлениях (нейронные сети; гибридные системы; рассуждения, основанные на прецедентах; рассуждения, основанные на ограничениях) нельзя ожидать и появления коммерческих продуктов.

Итак, в области искусственного интеллекта наибольшего коммерческого успеха достигли экспертные системы и средства для их разработки. В свою очередь, в этом направлении наибольшего успеха достигли проблемно/предметно специализированные средства. Если в 1988 году доход от них составил только 3 млн. долларов, то в 1993 году - 55 млн. долларов.

Экспертные системы реального времени - основное направление искусственного интеллекта

Среди специализированных систем, основанных на знаниях, наиболее значимы экспертные системы реального времени, или динамические экспертные системы. На их долю приходится 70 процентов этого рынка. Значимость инструментальных средств реального времени определяется не столько их бурным коммерческим успехом (хотя и это достойно тщательного анализа), но, в первую очередь, тем, что только с помощью подобных средств создаются стратегически значимые приложения в таких областях, как управление непрерывными производственными процессами в химии, фармакологии, производстве цемента, продуктов питания и т.п., аэрокосмические исследования, транспортировка и переработка нефти и газа, управление атомными и тепловыми электростанциями, финансовые операции, связь и многие другие. Классы задач, решаемых экспертными системами реального времени, таковы: мониторинг в реальном масштабе времени, системы управления верхнего уровня, системы обнаружения неисправностей, диагностика, составление расписаний, планирование, оптимизация, системы-советчики оператора, системы проектирования. Статические экспертные системы не способны решать подобные задачи, так как они не выполняют требования, предъявляемые к системам, работающим в реальном времени: 1. Представлять изменяющиеся во времени данные, поступающие от внешних источников, обеспечивать хранение и анализ изменяющихся данных. 2. Выполнять временные рассуждения о нескольких различных асинхронных процессах одновременно (т.е. планировать в соответствии с приоритетами обработку поступивших в систему процессов). 3. Обеспечивать механизм рассуждения при ограниченных ресурсах (время, память). Реализация этого механизма предъявляет требования к высокой скорости работы системы, способности одновременно решать несколько задач (т.е. операционные системы UNIX, VMS, Windows NT, но не MS-DOS). 4. Обеспечивать "предсказуемость" поведения системы, т.е. гарантию того, что каждая задача будет запущена и завершена в строгом соответствии с временными ограничениями. Например, данное требование не допускает использования в экспертной системе реального времени механизма "сборки мусора", свойственного языку Lisp. 5. Моделировать "окружающий мир", рассматриваемый в данном приложении, обеспечивать создание различных его состояний. 6. Протоколировать свои действия и действия персонала, обеспечивать восстановление после сбоя. 7. Обеспечивать наполнение базы знаний для приложений реальной степени сложности с минимальными затратами времени и труда (необходимо использование объектно-ориентированной технологии, общих правил, модульности и т.п.). 8. Обеспечивать настройку системы на решаемые задачи (проблемная/предметная ориентированность). 9. Обеспечивать создание и поддержку пользовательских интерфейсов для различных категорий пользователей. 10. Обеспечивать уровень защиты информации (по категориям пользователей) и предотвращать несанкционированный доступ. Подчеркнем, что кроме этих десяти требований средства создания экспертных систем реального времени должны удовлетворять и перечисленным выше общим требованиям.

Основные производители

Инструментарий для создания экспертных систем реального времени впервые выпустила фирма Lisp Machine Inc в 1985 году. Этот продукт предназначался для символьных ЭВМ Symbolics и носил название Picon. Его успех привел к тому, что группа ведущих его разработчиков образовала фирму Gensym, которая, значительно развив идеи, заложенные в Picon, выпустила в 1988 году инструментальное средство под названием G2. В настоящий момент работает его третья версия и подготовлена четвертая [1,7]. С отставанием от Gensym на два-три года ряд других фирм начал создавать (или пытаться создавать) свои инструментальные средства. Назовем ряд из них: RT Works (фирма Talarian, США), COMDALE/C (Comdale Techn., Канада), COGSYS (SC, США), ILOG Rules (ILOG, Франция). Сравнение двух наиболее продвинутых систем, G2 и RT Works, которое проводилось путем разработки одного и того же приложения двумя организациями, NASA (США) и Storm Integration (США) [10], показало значительное превосходство первой.

Архитектура экспертной системы реального времени

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

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

Жизненный цикл приложения

Жизненный цикл приложения в G2 состоит из ряда этапов.

Разработка прототипа приложения

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

Расширение прототипа до приложения

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

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

Тестирование приложения на наличие ошибок

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

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

Для выявления ошибок и неопределенностей реализована возможность "Inspect", позволяющая просматривать различные аспекты базы знаний, например, "показать все утверждения со ссылками на неопределенные сущности (объекты, связи, атрибуты)", "показать графически иерархию заданного класса объектов", "показать все сущности, у которых значение атрибута Notes не ОК". (Данный атрибут есть у всех сущностей, представимых в языке G2; его значение - либо ОК, когда нет претензий к сущности, либо описание реальных или потенциальных проблем, например, ссылка на несуществующий объект, несколько объектов с одним именем и т.п.)

Тестирование логики приложения и ограничений (по времени и памяти)

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

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

Полученное приложение полностью переносимо на различные платформы в среду UNIX (SUN, DEC, HP, IBM и т.д.), VMS (DEC VAX) и Windows NT (Intel, DEC Alpha). База знаний сохраняется в обычном ASCII-файле, который однозначно интерпретируется на любой из поддерживаемых платформ. Перенос приложения не требует его перекомпиляции и заключается в простом перемещении файлов. Функциональные возможности и внешний вид приложения не претерпевают при этом никаких изменений. Приложение может работать как в "полной" (т.е. предназначенной для разработки) среде, так и под runtime, которая не позволяет модифицировать базу знаний.

Сопровождение приложения

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

Основные компоненты

Экспертная система реального времени состоит из базы знаний, машины вывода, подсистемы моделирования и планировщика.

Базы знаний

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

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

Знания структурируются: предусмотрены иерархия классов, иерархия модулей, иерархия рабочих пространств. Каждую из них можно показать на дисплее.

Сущности и иерархия классов

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

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

Бр3ЮИерархия модулей и рабочих пространств

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

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

Рабочие пространства являются контейнерным классом, в котором размещаются другие классы и их экземпляры, например, объекты, связи, правила, процедуры и т.д. Каждый модуль (база знаний) может содержать любое число рабочих пространств. Рабочие пространства образуют одну или несколько древовидных иерархий с отношением "is-а-part-of" ("является частью"). С каждым модулем ассоциируется одно или несколько рабочих пространств верхнего (нулевого) уровня; каждое из них - корень соответствующей иерархии. В свою очередь, с каждым объектом (определением объекта или связи), расположенным в нулевом уровне, может ассоциироваться рабочее пространство первого уровня, "являющееся его частью" и т.д.

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

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

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

Бр3ЮСтруктуры данных

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

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

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

Выполняемые утверждения

Основу выполняемых утверждений баз знаний составляют правила и процедуры. Кроме того, есть формулы, функции, действия и т.п. Правила в G2 имеют традиционный вид: левая часть (антецедент) и правая часть (консеквент). Кроме if-правила, используется еще четыре типа правил: initially, unconditionally, when и whenever. Каждое из типов правил может быть как общим, т.е. относящимся ко всему классу, так и специфическим, относящимся к конкретным экземплярам класса.

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

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

Машина вывода, подсистема моделирования и планировщики

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

  1. Данные, входящие в антецедент правила изменились (прямой вывод - forward chaining).
  2. Правило определяет значение переменной, которое требуется другому правил или процедуре (обратный вывод - backward chaining).
  3. Каждые n секунд, где n - число, определенное для данного правила (сканирование - scan).
  4. Явное или неявное возбуждение другим правилом - путем применения действий фокусирования и возбуждения (focus и invoke).
  5. Каждый раз при запуске приложения.
  6. Входящей в антецедент переменной присвоено значение, независимо от того, изменилось оно или нет.
  7. Определенный объект на экране перемещен пользователем или другим правилом.
  8. Определенное отношение между объектами установлено или уничтожено.
  9. Переменная не получила значения в результате обращения к своему источнику данных.

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

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

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

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

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

Заключение

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

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

Литература

  1. F. Hayes-Roth, N. Jacobstein. The State of Enowledge-Based Systems. Communications of the АСМ, March, 1994, v.37, n.3, рр.27-39.
  2. Р. Harmon. The Size of the Commercial AI Market in the US. Intelligent Software Strategies. 1994, v.10, n.1, рр. 1-6.
  3. Expert system saves 20 million L on pipeline management. C&I July, 1994, р.31.
  4. Р. Harmon. The Market for Intelligent Software Products. Intelligent Sopware Strategies 1992, v.8, n.2, рр.5-12.
  5. D.R Perley. Migrating to Open Systems: Taming he Tiger. McGraw-Hill, 1993, р.252.
  6. Р. Harmon. The AI Tools Market The Market for Intelligent Software Building Tools. Part I. Intelligent Softwane Strategies, 1994, v 10, n.2, pp.1-14.
  7. Р. Harmon. The market for intelligent software pnducts Intelligent Software Strategies, 1992, v.8, n.2, рр.5-12.
  8. B.R. Clements and F. Preto. Evaluating Commencial Real Time Expert System Software for Use in the Process Industries. C&I, 1993, рр. 107-114.
  9. В. Мооге et al. Questions and Answers about G2. 1993. Gensym Corporation. рр.26-28.
  10. B. Moore. Memorandum. 1993, April. Gensym Corparation.
  11. Р. Богатырев. "Этот странный придуманный мир". Компьютерра. c.30-33. 1996 год.


Системы искусственного интеллекта

Морозов М.Н.
Курс лекций по дисциплине "Системы искусственного интеллекта"

Лекция 1: Введение

Лекции 2-3: Модели и методы решения задач

Лекция 4: Представление знаний в интеллектуальных системах

Лекция 5: Представление знаний в интеллектуальных системах (часть 2)

Лекция 6: Планирование задач

Лекции 7-8: Экспертные системы

Лекция 9: Методы работы со знаниями

Лекция 10: Системы понимания естественного языка

Лекция 11: Системы машинного зрения

Лекция 12: Тенденции развития систем искусственного интеллекта


Леоненков. Самоучитель UML.

ОГЛАВЛЕНИЕ

  • Глава 1. Введение
  • Глава 2. Исторический обзор развития методологии объектно-ориентированного анализа и проектирования сложных систем
  • Глава 3. Основные компоненты языка UML
  • Глава 4. Диаграмма вариантов использования (use case diagram)
  • Глава 5. Диаграмма классов (class diagram)
  • Глава 6. Диаграмма состояний (statechart diagram)
  • Глава 7. Диаграмма деятельности (activity diagram)
  • Глава 8. Диаграмма последовательности (sequence diagram)
  • Глава 9. Диаграмма кооперации (collaboration diagram)
  • Глава 10. Диаграмма компонентов (component diagram)
  • Глава 11. Диаграмма развертывания (deployment diagram)
  • Глава 12. Особенности реализации языка UML в CASE-инструментарии Rational Rose 98/2000
  • Заключение
На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 1
Введение

  • 1.1. Методология процедурно-ориентированного программирования
  • 1.2. Методология объектно-ориентированного программирования
  • 1.3. Методология объектно-ориентированного анализа и проектирования
  • 1.4. Методология системного анализа и системного моделирования

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

1.1. Методология процедурно-ориентированного программирования

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

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

Примечание

Принято считать, что сам термин алгоритм происходит от имени средневекового математика Аль-Хорезми, который в 825 г. описал правила выполнения арифметических действий в десятичной системе счисления.

С этой точки зрения вся история математики тесно связана с разработкой тех или иных алгоритмов решения актуальных для своей эпохи задач. Более того, само понятие алгоритма стало предметом соответствующей теории — теории алгоритмов, которая занимается изучением общих свойств алгоритмов. Со временем содержание этой теории стало настолько абстрактным, что соответствующие результаты понимали только специалисты. Как дань этой традиции какой-то период времени языки программирования назывались алгоритмическими, а первое графическое средство документирования программ получило название блок-схемы алгоритма. Соответствующая система графических обозначений была зафиксирована в ГОСТ 19.701-90, который регламентировал использование условных обозначений в схемах алгоритмов, программ, данных и систем.

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

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

Важным свойством таких программ является необходимость завершения всех действий предшествующей процедуры для начала действий последующей процедуры. Изменение порядка выполнения этих действий даже в пределах одной процедуры потребовало включения в языки программирования специальных условных операторов типа if-then-eise и Goto для реализации ветвления вычислительного процесса в зависимости от промежуточных результатов решения задачи.

Рис. 1.1. Графическое представление программы в виде последовательности процедур

Примечание

Появление и интенсивное использование условных операторов и оператора безусловного перехода стало предметом острых дискуссий среди специалистов по программированию. Дело в том, что бесконтрольное применение в программе оператора безусловного перехода goto способно серьезно осложнить понимание кода. Соответствующие программы стали сравнивать со спагетти, называя их bowl of spaghetti, имея в виду многочисленные переходы от одного фрагмента программы к другому, или, что еще хуже, возврат от конечных операторов программы к ее начальным операторам. Ситуация казалась настолько драматичной, что в литературе зазвучали призывы исключить оператор goto из языков программирования. Именно с этого времени принято считать хорошим стилем программирования — программирование без goto.

Рассмотренные идеи способствовали становлению некоторой системы взглядов на процесс разработки программ и написания программных кодов, которая Получила название методологии структурного программирования. Основой данной методологии является процедурная декомпозиция программной системы и организация отдельных модулей в виде совокупности выполняемых процедур. В рамках данной методологии получило развитие нисходящее проектирование программ или программирование "сверху-вниз". Период наибольшей популярности идей структурного программирования приходится на конец 70-х—начало 80-х годов.

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

Листинг 1.1. Пример фрагмента программы на Pascal, разработанной с использованием правил структурного программирования

Procedure FirstOpt;

  Begin

    FuncRaz(Free, Rn);

    for i:=l to N do

      RvarRec[i]:= Rn[i];

    FvarRec:= Freс;

    Numlt:=0;

    Repeat

      NumIt:=NumIt+l;

      V:= Freс;

        for j:=1 to К do

          for 1:=1 to M do

            begin

              S:=0.0;

              T:=0.0;

              for i:=l to N do

                begin

                  T:=T+sqr(Wl[i,j])*Xpr[i,l];

                  S:=S+sqr(Wl[i,j])

                end;

              Zentr[j,l]:=T/S

            end;

          for j:=1 to К do

            for i:=l to N do

              begin

                S:=0.0;

                P:=0.0;

                Q:=0.0;

                for l:=1 to M do

                  S:=S+sqr(Xpr[i,l]-Zentr[j,l]);

                P:=1.0/S;

              end;

            Q:=0.0;

            D:=0;

            for i:=1 to N do

              for j:=1 to К do

                if Abs(Wl[i,j]-W2[i,j]) >= Eps then D:=l;

              for i:=l to N do

                for j:=1 to К do

                  W1[i,j]:=W2[i,j]

  Until (D=0)or(NumIt=NumMax)

End;

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

Примечание

Сейчас попытки оценить профессионализм программиста количеством строк программного кода могут вызвать лишь улыбку собеседника. Действительно, используя встроенные мастера современных инструментариев разработки (MS Visual C++ или Inprise/Borland Delphi), даже новичок может за считанные секунды последовательным нажатием кнопок диалоговых меню создать работоспособное приложение, содержащее сотни строк программного кода и состоящее из десятка отдельных файлов проекта.

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

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

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

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

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

Примечание

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

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

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

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

Примечание

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

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

Для иллюстрации принципа наследования можно привести следующий пример. Рассмотрим в качестве общего класс "Автомобиль". Данный класс определяется как некоторая абстракция свойств и поведения всех реально существующих автомобилей. При этом свойствами класса "Автомобиль" могут быть такие общие свойства, как наличие двигателя, трансмиссии, колес, рулевого управления. Если в качестве производного класса рассмотреть класс "Легковой автомобиль", то все выделенные выше свойства будут присущи и этому классу. Можно сказать, что класс "Легковой автомобиль" наследует свойства родительского класса "Автомобиль". Однако, кроме перечисленных свойств, класс-потомок будет содержать дополнительные свойства, например такое, как наличие салона с количеством посадочных мест 2—5.

В свою очередь, класс "Легковой автомобиль" способен порождать другие подклассы, которые вполне могут соответствовать, например, моделям конкретных фирм-производителей. Таким образом, можно рассматривать класс "Легковой автомобиль производства ВАЗ". Поскольку Волжский автомобильный завод выпускает несколько моделей автомобилей, одним из производных классов для предыдущего класса может быть конкретная модель автомобиля, например, ВАЗ-21083. Наконец, изготовленный автомобиль имеет уникальный заводской номер, отличающий один автомобиль от другого. Таким номером может быть, например, XTA-210830S1594301. В последнем случае класс будет состоять из единственного объекта или экземпляра, которым будет являться легковой автомобиль производства ВАЗ с указанным выше заводским номером.

Описанная выше информация о соотношении классов в нашем примере обладает одним серьезным недостатком, а именно отсутствием наглядности. В этой связи возникает вопрос: а возможно ли представить иерархию наследования классов в визуальной форме? Традиционно для изображения понятий в формальной логике использовались окружности или прямоугольники. Тогда для рассмотренного примера иерархия порождения классов может быть представлена в виде вложенных прямоугольников, каждый из которых соответствует отдельному классу (рис. 1.2).

Рис. 1.2. Иерархия вложенности классов для примера "Автомобиль"

Появление объектно-ориентированных языков программирования было связано с необходимостью реализации концепции классов и объектов на синтаксическом уровне. С точки зрения ООП класс является дальнейшим расширением структуры (structure) или записи (record). Включение в известные языки программирования С и Pascal классов и некоторых других возможностей привело к появлению соответственно C++ и Object Pascal, которые на сегодня являются наиболее распространенными языками разработки приложений. Распространению C++ и Object Pascal способствовало то обстоятельство, что язык C++ был выбран в качестве базового для программного инструментария MS Visual C++, а язык Object Pascal— для популярного средства быстрой разработки приложений Borland/Inprise Delphi.

За короткий период времени оба инструментария превратились в мощные системы разработки программ с соответствующими библиотеками стандартных классов, содержащих сотни различных свойств и методов. Применительно к среде MS Visual C++ 5/6 такая библиотека имеет специальное название — MFC (Microsoft Foundation Classes), т. е. фундаментальные классы от Microsoft. При этом производные классы наследуют свойства и методы родительских классов. Ниже приводится фрагмент иерархии классов MFC в том виде, как он изображен в соответствующей документации (рис. 1.3).

Рис. 1.3. Фрагмент иерархии классов MFC, используемых в среде программирования MS Visual C++ 5/6

Рис. 1.4. Фрагмент иерархии классов VCU используемых в среде программирования Borland/Inprise Delphi 3-4

Процесс разработки программ в среде Borland/Inprise Delphi также тесно связан с использованием библиотеки стандартных классов — VCL (Visual Component Library) или библиотеки визуальных компонентов. Эта библиотека тоже построена по иерархическому принципу, в соответствии с которым компоненты нижележащих уровней наследуют свойства и методы вышележащих компонентов. Для данного случая также приводится фрагмент иерархии классов VCL (рис. 1.4).

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

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

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

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

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

Рис. 1.5. Иллюстрация сокрытия внутренних деталей реализации методов классов

Примечание

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

Третьим принципом ООП является полиморфизм. Под полиморфизмом (греч. Poly— много, morfos — форма) понимают свойство некоторых объектов принимать различные внешние формы в зависимости от обстоятельств. Применительно к ООП полиморфизм означает, что действия, выполняемые одноименными методами, могут отличаться в зависимости от того, какому из классов относится тот или иной метод.

Рассмотрим, например, три объекта или класса: двигатель автомобиля, электрический свет в комнате и персональный компьютер. Для каждого из них можно определить операцию "выключить". Однако сущность этой операции будет отличаться для каждого из рассмотренных объектов. Так для двигателя автомобиля вызов метода двигатеяь_автомобиля. выключить о означает прекращение подачи топлива и его остановку. Вызов метода Комната. электрический_ свет. выключить о означает простой щелчок выключателя, после чего комната погрузится в темноту. В последнем случае действие персональный_ компьютер. выключить о может быть причиной потери данных, если выполняется нерегламентированным образом.

Примечание

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

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

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

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

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

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

1.3. Методология объектно-ориентированного анализа и проектирования

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

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

Для выделения или идентификации компонентов предметной области было предложено несколько способов и правил. Сам этот процесс получил название концептуализации предметной области. При этом под компонентой понимают некоторую абстрактную единицу, которая обладает функциональностью, т. е. может выполнять определенные действия, связанные с решением поставленных задач. На предварительном этапе концептуализации рекомендуется использовать так называемые CRC-карточки (Component, Responsibility, Collaborator— компонента, обязанность, сотрудники) [1]. Для каждой выделенной компоненты предметной области разрабатывается собственная CRC-карточка (рис. 1.6).

Рис. 1.6. Общий вид CRC-карточки для описания компонентов предметной области

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

Разделение процесса разработки сложных программных приложений на отдельные этапы способствовало становлению концепции жизненного цикла программы. Под жизненным циклом (ЖЦ) программы понимают совокупность взаимосвязанных и следующих во времени этапов, начиная от разработки требований к ней и заканчивая полным отказом от ее использования. Стандарт ISO/IEC 12207, хотя и описывает общую структуру ЖЦ программы, не конкретизирует детали выполнения тех или иных этапов. Согласно принятым взглядам ЖЦ программы состоит из следующих этапов:

  • Анализа предметной области и формулировки требований к программе
  • Проектирования структуры программы
  • Реализации программы в кодах (собственно программирования)
  • Внедрения программы
  • Сопровождения программы
  • Отказа от использования программы

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

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

Этап программирования вряд ли нуждается в уточнении, поскольку является наиболее традиционным для программистов. Появление инструментариев быстрой разработки приложений (Rapid Application Development, RAD) позволило существенно сократить время, и затраты на выполнение этого этапа. Результатом данного этапа является программное приложение, которое обладает требуемой функциональностью и способно решать нужные задачи в конкретной предметной области.

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

Примечание

Рассматривая различные этапы ЖЦ программы, следует отметить одно важное обстоятельство. А именно, если появление RAD-инструментариев позволило существенно сократить сроки этапа программирования, то отсутствие соответствующих средств для первых двух этапов долгое время сдерживало процесс разработки приложений. Развитие методологии ООАП было направлено на автоматизацию второго, а затем и первого этапов ЖЦ программы.

Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE). Появление первых CASE-средств было встречено с определенной настороженностью. Со временем появились как восторженные Отзывы об их применении, так и критические оценки их возможностей. Причин для столь противоречивых мнений было несколько. Первая из них заключается в том, что ранние CASE-средства были простой надстройкой над некоторой системой управления базами данных (СУБД). Хотя визуализация процесса разработки концептуальной схемы БД имеет немаловажное значение, она не решает проблем разработки приложений других типов.

Вторая причина имеет более сложную природу, поскольку связана с графической нотацией, реализованной в том или ином CASE-средстве. Если языки программирования имеют строгий синтаксис, то попытки предложить подходящий синтаксис для визуального представления концептуальных схем БД были восприняты далеко неоднозначно. Появилось несколько подходов, которые более подробно будут рассмотрены в главе 2. На этом фоне появление унифицированного языка моделирования (Unified Modeling Language, UML), который ориентирован на решение задач первых двух этапов ЖЦ программ, было воспринято с большим оптимизмом всем сообществом корпоративных программистов.

Примечание

Аббревиатура UML допускает соответствующий перевод и последующее сокращение, но ввиду неудобочитаемости получающегося "УЯМ" было решено использовать исходный термин на всем протяжении книги. Частично это можно объяснить уже сложившейся традицией применения оригинальных терминов, таких как CASE, RAD, DLL, ISDN и целого ряда других.

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

1.4. Методология системного анализа и системного моделирования

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

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

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

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

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

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

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

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

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

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

Примечание

Термин "моделирование" имеет довольно много смысловых оттенков, например, моделирование одежды или моделирование прически. Не отрицая важности этих сфер творчества, следует отметить, "что все эти аспекты моделирования лежат за пределами книги. Рассмотрение особенностей языка UML связано с вопросами логического или информационного моделирования систем.

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

Рис. 1.7. Графическое изображение модели системы в виде "черного ящика"

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

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

Сложность системы и, соответственно, ее модели может быть рассмотрена с различных точек зрения. Прежде всего, можно выделить сложность структуры системы, которая характеризуется количеством элементов системы и различными типами взаимосвязей между этими элементами. Если количество элементов превышает некоторое пороговое значение, которое не является строго фиксированным, то такая система может быть названа сложной. Например, если программная СУБД насчитывает более 100 отдельных форм ввода и вывода информации, то многие программисты сочтут ее сложной. Транспортная система современных мегаполисов также может служить примером сложной системы.

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

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 10
Диаграмма компонентов (component diagram)

  • 10.1. Компоненты
    • Имя компонента
    • Виды компонентов
  • 10.2. Интерфейсы
  • 10.3. Зависимости
  • 10.4. Рекомендации по построению диаграммы компонентов

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

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

Чтобы пояснить отличие логического и физического представлений, рассмотрим в общих чертах процесс разработки некоторой программной системы. Ее исходным логическим представлением могут служить структурные схемы алгоритмов и процедур, описания интерфейсов и концептуальные схемы баз данных. Однако для реализации этой системы необходимо разработать исходный текст программы на некотором языке программирования (C++, Pascal, Basic/VBA, Java). При этом уже в тексте программы предполагается такая организация программного кода, которая предполагает его разбиение на отдельные модули.

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

Таким образом, полный проект программной системы представляет собой совокупность моделей логического и физического представлений, которые должны быть согласованы между собой. В языке UML для физического представления моделей систем используются так называемые диаграммы реализации (implementation diagrams), которые включают в себя две отдельные канонические диаграммы: диаграмму компонентов и диаграмму развертывания. Особенности построения первой из них рассматриваются в этой главе, а второй — в следующей.

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

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

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

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

Примечание

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

10.1. Компоненты

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

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

Рис. 10.1. Графическое изображение компонента в языке UML

Так, в первом случае (рис. 10.1, а) с компонентом уровня экземпляра связывается только его имя, а во втором (рис. 10.1, б) — дополнительно имя пакета и помеченное значение.

Примечание

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

Имя компонента

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

Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается <имя компонента ':' имя типаХ При этом вся строка имени подчеркивается.

Примечание

Хотя правила именования объектов в языке UML требуют подчеркивания имени отдельных экземпляров, применительно к компонентам в литературе подчеркивание их имени часто опускают. В этом случае запись имени компонента со строчной буквы будет характеризовать компонент уровня экземпляра.

В качестве простых имен принято использовать имена исполняемых файлов (с указанием расширения ехе после точки-разделителя), имена динамических библиотек (расширение dll), имена Web-страниц (расширение html), имена текстовых файлов (расширения txt или doc) или файлов справки (hip), имена файлов баз данных (DB) или имена файлов с исходными текстами программ (расширения h, cpp для языка C++, расширение Java для языка Java), скрипты (pi, asp) и др.

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

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

Виды компонентов

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

В языке UML выделяют три вида компонентов.

  • Во-первых, компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll (рис. 10.2, а), Web-страницы на языке разметки гипертекста с расширением html (рис. 10.2, б) и файлы справки с расширением Ыр (рис. 10.2, в).
  • Во-вторых, компоненты-рабочие продукты. Как правило — это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++ (рис. 10.2, г).
  • В-третьих, компоненты исполнения, представляющие исполнимые модули — файлы с расширением ехе. Они обозначаются обычным образом.

Рис. 10.2. Варианты графического изображения компонентов на диаграмме компонентов

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

Другой способ спецификации различных видов компонентов — явное указание стереотипа компонента перед его именем. В языке UML для компонентов определены следующие стереотипы:

  • Библиотека (library) — определяет первую разновидность компонента, который представляется в форме динамической или статической библиотеки.
  • Таблица (table) — также определяет первую разновидность компонента, который представляется в форме таблицы базы данных.
  • Файл (file) — определяет вторую разновидность компонента, который представляется в виде файлов с исходными текстами программ.
  • Документ (document) — определяет вторую разновидность компонента, . который представляется в форме документа.
  • Исполнимый (executable) — определяет третий вид компонента, который может исполняться в узле.

10.2. Интерфейсы

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

Рис. 10.3. Графическое изображение интерфейсов на диаграмме компонентов

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

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

Примечание

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

10.3. Зависимости

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

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

В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 10.4). Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент диаграммы компонентов представляет информацию о том, что компонент с именем "main.exe" зависит от импортируемого интерфейса I Dialog, который, в свою очередь, реализуется компонентом с именем "image.java". Для второго компонента этот же интерфейс является экспортируемым.

Рис. 10.4. Фрагмент диаграммы компонентов с отношением зависимости

Заметим, что изобразить второй компонент с именем "image.java" в форме варианта примечания нельзя именно в силу того факта, что этот компонент реализует интерфейс.

Другим случаем отношения зависимости на диаграмме компонентов является отношение между различными видами компонентов (рис. 10.5). Наличие подобной зависимости означает, что внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента. При этом характер изменений может быть отмечен дополнительно.

Рис. 10.5. Графическое изображение отношения зависимости между компонентами

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

Рис. 10.6. Графическое изображение зависимости между компонентом и классами

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

Рис. 10.7. Графическое изображение компонента с дополнительной информацией о реализуемых им классах

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

Рис. 10.8. Графическое изображение компонента уровня экземпляра, реализующего отдельные объекты

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

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

10.4. Рекомендации по построению диаграммы компонентов

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

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

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

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

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

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

Если же проект содержит некоторые физические элементы, описание которых отсутствует в языке UML, то следует воспользоваться механизмом расширения. В частности, использовать дополнительные стереотипы для отдельных нетиповых компонентов или помеченные значения для уточнения их отдельных характеристик.

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

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 11
Диаграмма развертывания (deployment diagram)

  • 11.1. Узел
  • 11.2. Соединения
  • 11.3. Рекомендации по построению диаграммы развертывания

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

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

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

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

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

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

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

Итак, перечислим цели, преследуемые при разработке диаграммы развертывания:

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

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

11.1. Узел

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

Примечание

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

Графически на диаграмме развертывания узел изображается в форме трехмерного куба (строго говоря, псевдотрехмерного прямоугольного параллелепипеда). Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов (рис. 11.1, а), так и в качестве экземпляров (рис. 11.1, б).

Рис. 11.1. Графическое изображение узла на диаграмме развертывания

В первом случае имя узла записывается без подчеркивания и начинается с заглавной буквы. Во втором имя узла-экземпляра записывается в виде <имя узла ':' имя типа узла>. Имя типа узла указывает на некоторую разновидность узлов, присутствующих в модели системы.

Например, аппаратная часть системы может состоять из нескольких персональных компьютеров, каждый из которых соответствует отдельному узлу-экземпляру в модели. Однако все эти узлы-экземпляры относятся к одному типу узлов, а именно узлу с именем типа "Персональный компьютер". Так, на представленном выше рисунке (рис. 11.1, а) узел с именем "Сервер" относится к общему типу и никак не конкретизируется. Второй же узел (рис. 11.1, б) является анонимным узлом-экземпляром конкретной модели принтера.

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

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

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

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

Рис. 11.3. Варианты графического изображения узлов-экземпляров с размещаемыми на них компонентами

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

Примечание

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

11.2. Соединения

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

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

Рис. 11.4. Фрагмент диаграммы развертывания с соединениями меходу узлами

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

Диаграммы развертывания могут иметь более сложную структуру, включающую вложенные компоненты, интерфейсы и другие аппаратные устройства. На изображенной ниже диаграмме развертывания (рис. 11.6) представлен фрагмент физического представления системы удаленного обслуживания клиентов банка. Узлами этой системы являются удаленный терминал (узел-тип) и сервер банка (узел-экземпляр).

Рис. 11.5. Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем компонентами

Рис. 11.6. Диаграмма развертывания для системы удаленного обслуживания клиентов банка

На этой диаграмме развертывания указана зависимость компонента реализации диалога "dialog.exe" на удаленном терминале от интерфейса lAuthorise, реализованного компонентом "main.exe", который, в свою очередь, развернут на анонимном узле-экземпляре "Сервер банка". Последний зависит от компонента базы данных "Клиенты банка", который развернут на этом же узле.

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

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

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

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

Вариант физического представления этой транспортной системы показан на следующей диаграмме развертывания (рис. 11.7).

Рис. 11.7. Диаграмма развертывания для модели системы управления транспортной платформой

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

11.3. Рекомендации по построению диаграммы развертывания

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

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

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

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

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

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

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

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

В главе 12 некоторые из этих аспектов будут рассмотрены более подробно на примере CASE-средства Rational Rose 98/981.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 12
Особенности реализации языка UML в CASE-инструментарии Rational Rose 98/2000

  • 12.1. Общая характеристика CASE-средства Rational Rose 98/2000
  • 12.2. Особенности рабочего интерфейса Rational Rose
    • Главное меню программы
    • Стандартная панель инструментов
    • Окно браузера
    • Специальная панель инструментов
    • Окно диаграммы
    • Окно документации
    • Окно журнала
  • 12.3. Начало работы над проектом в среде Rational Rose
  • 12.4. Разработка диаграммы вариантов использования в среде Rational Rose
  • 12.5. Разработка диаграммы классов вереде Rational Rose
  • 12.6. Разработка диаграммы состояний в среде Rational Rose
  • 12.7. Разработка диаграммы последовательности в среде Rational Rose
  • 12.8. Разработка диаграммы кооперации в среде Rational Rose
  • 12.9. Разработка диаграммы компонентов в среде Rational Rose
  • 12.10. Разработка диаграммы развертывания в среде Rational Rose

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

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

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

Среди всех фирм-производителей CASE-средств именно компания Rational Software Coip. одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования.

Примечание

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

12.1. Общая характеристика CASE-средства Rational Rose 98/2000

CASE-средство Rational Rose со времени своего появления претерпело серьезную эволюцию и превратилось в современное и мощное средство анализа, моделирования и разработки программных систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации и разработки программ, что определило популярность и стратегическую перспективность этого инструментария.

В рамках Rational Rose существуют различные программные инструментарии, отличающиеся между собой диапазоном реализованных возможностей. Базовым средством в настоящее время остается Rational Rose 98, которое существует в четырех основных модификациях:

  • Rational Rose 98 Enterprise Edition
  • Rational Rose 98 Professional Edition
  • Rational Rose 98 Modeler Edition
  • Rational Rose 98 для UNIX

Наиболее полными возможностями обладает первая из указанных модификаций этого средства. Из этих возможностей можно отметить: реализацию UML версии 1.0, генерацию кодов на различных языках программирования (Java, C++, VisualBasic, PowerBuilder), обратную генерацию диаграмм (реинжиниринга) на основе программного кода и выпуск проектной документации.

Следующей версией стало средство Rational Rose 98i, которое также выпускается в этих же четырех модификациях. Эта версия дополнительно позволяет генерировать программный код стандарта MS Visual C++, обеспечивает документирование проекта в формате HTML для Web-публикации и поддерживает интеграцию с другими инструментариями объектно-ориентированной разработки программ, базами данных и с компонентами MS Office 2000.

Последней из версий на момент написания книги является Rational Rose 2000, возможности которой аккумулируют практически все современные достижения в области информационных технологий:

  • Интеграция с MS Visual Studio 6, что включает в себя поддержку на уровне прямой и обратной генерации кодов и диаграмм VB 6, Visual C++ 6, Visual J++ 6 (ATL-Microsoft Active Template Library, Web-Classes, DHTML, Data Connections).
  • Непосредственная работа (инжиниринг и реинжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX.
  • Поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов стратегической технологии Microsoft — СОМ+ (DCOM).
  • Полная поддержка CORBA 2.2, включая реализацию технологии компонентной разработки приложений CBD (Component-Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL (Data Definition Language).
  • Полная поддержка среды разработки Java-приложений JDK 1.2, включая прямую и обратную генерацию классов Java формата JAR, а также работу с файлами форматов CAB и ZIP.

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

Примечание

Конечно, рассмотреть в одной главе возможности такого средства, как Rational Rose 2000, просто невозможно, и автор не ставил перед собой такую задачу. Цель нашего знакомства с этим инструментарием — осветить основные особенности реализации языка UML на уровне разработки отдельных диаграмм. Поэтому далее описываются лишь основные правила и рекомендации, необходимые для разработки визуальных моделей в форме канонических диаграмм языка UML, реализованные уже в Rational Rose 98 и, соответственно, в Rational Rose 98J/2000.

12.2. Особенности рабочего интерфейса Rational Rose

В CASE-средстве Rational Rose реализованы общепринятые стандарты на рабочий интерфейс программы, подобно известным средам визуального программирования. После установки Rational Rose на компьютер пользователя, что практически не вызывает трудностей даже у начинающих, запуск этой программы в среде MS Windows 95/98 приводит к появлению на экране рабочего интерфейса (рис. 12.1).

Рис. 12.1. Общий вид рабочего интерфейса программы Rational Rose

Рабочий интерфейс Rational Rose состоит из различных элементов, основными из которых являются:

  • Главное меню программы
  • Окно диаграммы
  • Стандартная панель инструментов
  • Окно документации
  • Окно браузера
  • Окно журнала
  • Специальная панель инструментов

Рассмотрим кратко назначение и основные функции каждого из этих элементов.

Главное меню программы

Главное меню программы выполнено в общепринятом стандарте и имеет следующий вид (рис. 12.2).

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

Рис. 12.2. Внешний вид главного меню программы

Стандартная панель инструментов

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

Рис. 12.3. Внешний вид стандартной панели инструментов

Пользователь может настроить внешний вид этой панели по своему усмотрению. Для этого необходимо выбрать пункт меню Tools -> Options (Инструменты -> Параметры) и открыть вкладку Toolbars (Панели инструментов). Этим способом можно показать или скрыть различные кнопки инструментов, а также изменить их размер.

Примечание

Следует заметить, что внешний вид панели инструментов определяется не только выбором и не только видом разрабатываемой диаграммы, но и выбором графической нотации для изображения самих элементов этих диаграмм. В Rational Rose реализованы три таких нотации: UML, ОМТ и Booch. Речь идет о том, что одна и та же диаграмма может быть представлена различным образом, для этого достаточно выбрать желаемое представление через пункт меню View (Вид). При этом никаких дополнительных действий выполнять не требуется — диаграмма преобразуется в выбранную нотацию автоматически. Однако, рассматривая Rational Rose в контексте только языка UML, мы оставим без внимания особенности двух других нотаций, которые отражают эволюционный аспект этого средства.

Окно браузера

Окно браузера по умолчанию располагается в левой части рабочего интерфейса под стандартной панелью инструментов (рис. 12.4).

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

Рис. 12.4. Внешний вид браузера

Специальная панель инструментов

Специальная панель инструментов располагается между окном браузера и окном диаграммы в средней части рабочего интерфейса. По умолчанию предлагается панель инструментов для построения диаграммы классов модели (рис. 12.5).

Рис. 12.5. Внешний вид специальной панели инструментов для диаграммы классов

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

Окно диаграммы

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

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

Рис. 12.6. Внешний вид окна диаграмм с различными видами представлений модели

Окно документации

Окно документации по умолчанию может не присутствовать на экране. В этом случае оно может быть активизировано через пункт меню View -> Documentation (Вид->Документация), после чего появится ниже браузера (рис. 12.7).

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

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

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

Рис. 12.7. Внешний вид окна документации

Окно журнала

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

Окно журнала всегда присутствует на рабочем интерфейсе в области окна диаграммы (рис. 12.8). Однако оно может быть закрыто другими окнами с диаграммами или быть свернутым. Активизировать окно журнала можно через меню Window->Log (Окно->Журнал). В этом случае оно изображается поверх других окон в правой области рабочего интерфейса. Полностью удалить это окно нельзя, его можно только минимизировать.

Рис. 12.8. Внешний вид окна журнала

12.3. Начало работы над проектом в среде Rational Rose

Из всех рассмотренных видов канонических диаграмм в среде Rational Rose 98/98i не поддерживается только диаграмма деятельности. Общая последовательность работы над проектом аналогична последовательности рассмотрения канонических диаграмм в книге. Исходным шагом разработки нового проекта является создание отдельных моделей или представлений в контексте построения канонических диаграмм.

Для нового проекта можно воспользоваться мастером типовых проектов (если он установлен в данной конфигурации). Мастер типовых проектов доступен из меню File-»New (Файл^Создать). Если мастер недоступен, то появляется рабочий интерфейс программы с чистым окном диаграммы.

Если имеется готовый проект (файл с расширением mdl — модель), то его можно открыть для последующей модификации через меню FiIe-»Open (Файл->Открыть). В этом случае программа загрузит существующий проект со всеми имеющимися в нем диаграммами, спецификациями и документацией.

По окончании сеанса работы над проектом выполненную работу необходимо сохранить в файле проекта с расширением mdl. Это можно сделать через меню File-»Save (Файл->Сохранить) или File-»Save As (Файл-»Сохранить как). При этом вся информация о проекте, включая диаграммы и спецификации элементов, будет сохранена в одном файле.

Как и другие программы, Rational Rose позволяет настраивать глобальные параметры среды, такие как выбор шрифтов и цвета для представления различных элементов модели. Настройка шрифтов производится через меню Tools-»Options (Инструменты-»Параметры). Характерной особенностью среды является возможность работы с символами кириллицы. Однако следует заметить, что при спецификации элементов модели с последующей генерацией текста программного кода нужно сразу записывать имена и свойства элементов символами того языка, который поддерживается соответствующим языком программирования.

Для изменения цвета линий необходимо воспользоваться пунктом меню Edit-»Diagram Object Properties-»Line Color (Правка-»Свойства объекта диа-граммы-»Цвет линии). В этом случае предлагается специальная цветовая палитра, на которой можно выбрать подходящий цвет для линий на диаграммах.

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

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

12.4. Разработка диаграммы вариантов использования в среде Rational Rose

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

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

  • Раскрыть представление вариантов использования в браузере (Use Case View) и дважды щелкнуть на пиктограмме Main (Главная).
  • Через пункт меню Browse-Use Case Diagram (Браузер-»Диаграмма вариантов использования).

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

Рис. 12.9. Внешний вид специальной панели инструментов для диаграммы вариантов использования

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

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

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

Рис. 12.10. Пример разработки диаграммы вариантов использования в среде Rational Rose

Диаграмма вариантов использования является высокоуровневым представлением модели, поэтому она не должна содержать слишком много вариантов использования и актеров. В последующем построенная диаграмма может быть изменена добавлением новых элементов, таких как варианты использования и актеров, или их удалением. Для удаления элемента не только из диаграммы, но и из модели в целом необходимо выделить удаляемый элемент на диаграмме и воспользоваться пунктом меню Edit-»DeIete from Model.

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

За более подробной информацией по построению диаграмм вариантов использования в среде Rational Rose можно обратиться к специальной литературе [3].

12.5. Разработка диаграммы классов в среде Rational Rose

Диаграмма классов является основным логическим представлением модели и содержит самую подробную информацию о внутреннем устройстве объектно-ориентированной программной системы. Активизировать диаграмму классов в окне диаграммы можно также несколькими способами:

  • Эта диаграмма появляется по умолчанию в окне диаграммы после создания нового проекта.
  • Щелкнуть на кнопке с изображением диаграммы классов на стандартной панели инструментов.
  • Раскрыть логическое представление в браузере (Logical View) и дважды щелкнуть на пиктограмме Main (Главная).
  • Через пункт меню Browse->CIass Diagram (Браузер->Диаграмма классов).

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

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

  • Общий, открытый (Public) — устанавливается по умолчанию. Пример — атрибут 1 в классе 1. В этом случае атрибут виден всем остальным классам модели. Любой класс может просмотреть и изменить значение этого атрибута. В нотации языка UML такому атрибуту соответствует знак "+".
  • Защищенный (Protected). Пример — атрибут 2 в классе 1. В этом случае атрибут можно просмотреть и изменить из самого класса 1 или из его потомков. В нотации языка UML такому атрибуту соответствует знак "#".
  • Закрытый (Private). Пример — атрибут 3 в классе 1. В этом случае атрибут не виден никакому другому классу, кроме того, в котором он определен. В нотации языка UML такому атрибуту соответствует знак "-".
  • Пакетный (Implemented). Пример — атрибут 4 в классе 1. Такой атрибут является общим только в пределах своего пакета. В нотации языка UML для такого атрибута пиктограмма отсутствует.

Рис. 12.11. Пример графического изображения диаграммы классов в среде Rational Rose

Аналогичные пиктограммы применяются для обозначения видимости операций класса. Так, операция_1() класса 1 является защищенной и поэтому доступ к ней разрешен только из самого класса 1 или из его потомков. Опе-рация_2() этого же класса является закрытой и поэтому, кроме класса 1, она никакому другому классу не доступна.

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

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

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

12.6. Разработка диаграммы состояний в среде Rational Rose

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

  • Раскрыть логическое представление в браузере (Logical View), выделить рассматриваемый класс и выбрать пункт контекстного меню Open State Diagram (Открыть диаграмму состояний), раскрывающегося по щелчку правой кнопкой мыши.
  • Через пункт меню Browse-»State Diagram (Браузер-»Диаграмма состояний).

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

Рис. 12.12. Внешний вид специальной панели инструментов для диаграммы состояний

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

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

Рис. 12.13. Пример графического изображения диаграммы состояний в среде Rational Rose

12.7. Разработка диаграммы последовательности в среде Rational Rose

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

  • Щелкнуть на кнопке с изображением диаграммы последовательности на стандартной панели инструментов.

  • Через пункт меню Browse - Interaction Diagram (Браузер - Диаграмма взаимодействия).

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

Рис. 12.14. Внешний вид специальной панели инструментов для диаграммы последовательности

Построение диаграммы последовательности сводится к добавлению или удалению отдельных объектов и сообщений, а также к их спецификации. Доступ к спецификации этих элементов организован либо через контекстное меню, либо через пункт меню Browse - Specification (Браузер - Спецификация). При добавлении сообщений на диаграмму последовательности они получают по умолчанию свой номер в последовательности. Ниже приводится пример построенной диаграммы состояний (рис. 12.15).

Рис. 12.15. Пример графического изображения диаграммы последовательности в окне диаграммы среды Rational Rose

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

12.8. Разработка диаграммы кооперации в среде Rational Rose

Диаграмма кооперации является другим способом визуализации взаимодействия в модели и, как и диаграмма последовательности, оперирует объектами и сообщениями. Особенность работы в среде Rational Rose заключается в том, что этот вид канонической диаграммы создается автоматически после построения диаграммы последовательности и нажатия клавиши <F5>. С помощью этой же клавиши осуществляется переключение между диаграммами последовательности и кооперации.

После того как диаграмма кооперации активизирована, специальная панель инструментов приобретает следующий вид (рис. 12.16).

Рис. 12.16. Внешний вид специальной панели инструментов для диаграммы кооперации

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

Ниже представлен пример диаграммы кооперации (рис. 12.17), которая была автоматически сгенерирована средой после построения диаграммы последовательности (см. рис. 12.15).

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

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

12.9. Разработка диаграммы компонентов в среде Rational Rose

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

  • Щелкнуть на кнопке с изображением диаграммы компонентов на стандартной панели инструментов.
  • Раскрыть компонентное представление в браузере (Component View) и дважды щелкнуть на пиктограмме Main (Главная).
  • Через пункт меню Browse-»Component Diagram (Браузер-»Диаграмма компонентов).

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

Рис. 12.18. Внешний вид специальной панели инструментов для диаграммы компонентов

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

Ниже приводится пример графического изображения элементов диаграммы компонентов (рис. 12.19).

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

Рис. 12.19. Пример графического изображения диаграммы компонентов в среде Rational Rose

12.10. Разработка диаграммы развертывания в среде Rational Rose

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

  • Щелкнуть на кнопке с изображением диаграммы развертывания на стандартной панели инструментов.
  • Дважды щелкнуть на пиктограмме представления развертывания в браузере (Deployment View).
  • Через пункт меню Browse-»Deployment Diagram (Браузер-»Диаграмма развертывания).

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

Рис. 12.20. Внешний вид специальной панели инструментов для диаграммы развертывания

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

Ниже приводится пример графического изображения диаграммы развертывания (рис. 12.21).

Рис. 12.21. Пример графического изображения диаграммы развертывания в среде Rational Rose

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

Общая последовательность действий, которые необходимо выполнить для этого, состоит из шести этапов:

  1. Проверка модели независимо от выбора языка генерации кода.
  2. Создание компонентов для реализации классов.
  3. Отображение классов на компоненты.
  4. Установка свойств генерации программного кода.
  5. Выбор класса, компонента или пакета.
  6. Генерация программного кода.

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

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

Заключение

В настоящее время полностью специфицирована и документирована версия 1.3 языка UML и продолжается дальнейшая работа по его развитию. Хотя уже анонсирована следующая версия языка UML — 1.4, на момент написания книги окончательная документация по этой версии еще не специфицирована. Возможно, по этой причине следующей версией станет UML 2.0, работу над которой планируется развернуть в 2001 году. Ход этой работы и ее состояние отражаются на официальном сайте OMG: http://www.omg.org. Там же содержатся полные спецификации стандарта OMG-UML, предоставленные для свободного доступа.

Другим источником информации по языку UML в Интернете является сайт компании Rational Software Corp.: http://www.rational.com/, в которой сосредоточены основные разработчики и со стороны которой осуществляется общая координация работы над очередными версиями языка. Эта компания также является разработчиком CASE-средства Rational Rose 98/2000, в котором реализуются текущие дополнения языка UML.

Из отечественных ресурсов нельзя не упомянуть сайт компании "Интерфейс" — http://www.interface.ru, где содержится информация по многим современным CASE-средствам, рассматриваются их характеристики и возможности, а также особенности отдельных технологий ООАП.

Перспективы дальнейшего развития UML связаны со становлением и интенсивным развитием новой парадигмы объектно-ориентированного анализа — компонентной разработки приложений (Component-Based Development — CBD). В этой связи развернута работа над дополнительной спецификацией языка UML применительно к технологиям CORBA и СОМ+. Речь идет о разработке так называемых профилей, содержащих нотацию всех необходимых элементов для представления в языке UML компонентов соответствующих технологий. При этом интенсивно используется механизм расширения языка UML за счет добавления новых стереотипов, помеченных значений и ограничений.

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

В частности, для моделирования бизнес-процессов могут быть использованы: применительно к подсистемам — стереотипы "organization unit" и "work unit", для классов — стереотипы "worker", "case worker", "internal worker". При этом, например, стереотип "worker" служит для обозначения класса, который представляет абстракцию человека, выполняющего определенную деятельность или работу в бизнес-системе. Работник или сотрудник взаимодействует с другими сотрудниками подсистемы в процессе выполнения отдельных операций, образующих бизнес-логику процесса.

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

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

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

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

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

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

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 2
Исторический обзор развития методологии объектно-ориентированного анализа и проектирования сложных систем

  • 2.1. Предыстория. Математические основы
    • Теория множеств
    • Теория графов
    • Семантические сети
  • 2.2. Диаграммы структурного системного анализа
    • Диаграммы, "сущность-связь"
    • Диаграммы функционального моделирования
    • Диаграммы потоков данных
  • 2.3. Основные этапы развития UML

2.1. Предыстория. Математические основы

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

Теория множеств

Как одну из наиболее известных систем графических символов, оказавших непосредственное влияние на развитие научного мышления, следует отметить язык диаграмм английского логика Джона Венна (1834—1923). В настоящее время диаграммы Венна применяются для иллюстрации основных теоретико-множественных операций, которые являются предметом специального раздела математики — теории множеств. Поскольку многие общие идеи моделирования систем имеют адекватное описание в терминологии теории множеств, рассмотрим основные понятия данной теории, имеющие отношение к современным концепциям и технологиям исследования сложных систем.

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

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

Примечание

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

В теории множеств используется специальное соглашение, по которому множества обозначаются прописными буквами латинского алфавита, и традиция эта настолько общепризнана, что не возникает никакого сомнения в ее целесообразности. При этом отдельные элементы обозначаются строчными буквами, иногда с индексами, которые вносят некоторую упорядоченность в последовательность рассмотрения этих элементов. Важно понимать, что какой бы то ни было порядок, вообще говоря, не входит в исходное определение множества. Таким образом, множество, например, квартир 100-квартирного жилого дома с использованием специальных обозначений можно записать следующим образом: A={aj, 02, а3, ..., а{00}. Здесь фигурные скобки служат обозначением совокупности элементов, каждый из которых имеет свой уникальный числовой индекс. Важно понимать, что для данного конкретного множества элемент ato обозначает отдельную квартиру в рассматриваемом жилом доме. При этом вовсе необязательно, чтобы номер этой квартиры был равен 10, хотя с точки зрения удобства это было бы желательно.

Принято называть элементы отдельного множества принадлежащими данному множеству. Данный факт записывается при помощи специального символа "е", который так и называется — символ принадлежности. Например, запись а10ьА означает тот простой факт, что отдельная квартира (возможно, с номером 10) принадлежит рассматриваемому множеству квартир некоторого жилого дома.

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

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

Как же используются диаграммы Венна в теории множеств? Оказывается, тот факт, что некоторая совокупность элементов образует множество, можно обозначить графически в виде круга. В этом случае окружность имеет содержательный смысл или, выражаясь более точным языком, семантику границы данного множества. Очевидно, что рассмотрение отношения включения элементов одного множества в другое можно изобразить графически следующим образом (рис. 2.1). На этом рисунке большему множеству В соответствует внешний круг, а меньшему множеству (подмножеству) А — внутренний.

Рис. 2.1. Диаграмма Венна для отношения включения двух множеств

Подобным образом можно изобразить и основные теоретико-множественные операции. Так, пересечением двух множеств А и В называется некоторое третье множество С, которое состоит из тех и только тех элементов двух исходных множеств, которые одновременно принадлежат и множеству А, и множеству В. Для этой операции также имеется специальное обозначение: С= А о В. Например, если в качестве множества А для операции пересечения рассмотреть множество сотрудников некоторой фирмы, а в качестве множества В — множество всех мужчин, то нетрудно догадаться, что множество С будет состоять из элементов -± всех сотрудников мужского пола данной фирмы. Операция пересечения множеств также может быть проиллюстрирована с помощью диаграмм Венна (рис. 2.2). На этом рисунке условно изображены два множества А и В, затененной области как раз и соответствует множество С, являющееся пересечением множеств А и В.

Рис. 2.2 Диаграмма Венна для пересечения двух множеств

Следующей операцией, которая также допускает наглядную интерпретацию, является операция объединения множеств. Под объединением двух множеств А и В понимается некоторое третье множество, пусть это будет D, которое состоит из тех и только тех элементов, которые принадлежат или А, или В, или им обоим одновременно. Конечно, специальное обозначение есть и для этой операции: D= AuB. Так, если в качестве множества А рассмотреть множество, состоящее из клавиатуры и мыши, а в качестве множества В — множество, состоящее из системного блока и монитора, то нетрудно догадаться, что их объединение, т. е. множество D, образует основные составляющие персонального компьютера. И для этой операции имеется условное графическое представление (рис. 2.3). На этом рисунке объединению двух исходных множеств также соответствует затемненная область, только размеры и форма ее отличаются от случая пересечения двух множеств на предыдущем рисунке.

Рис. 2.3. Диаграмма Венна для объединения двух множеств

Примечание

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

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

Ситуация усложняется, когда рассматриваются бесконечные множества, т. е. множества, не являющиеся конечными. Не вдаваясь в технические детали, которые послужили источником драматичного по своим последствиям кризиса основ математики, ограничим наше рассмотрение бесконечными множествами счетной мощности. Такими множествами принято считать множества, содержащие бесконечное число элементов, которые, однако, можно перенумеровать натуральными числами 1, 2, 3 и т. д. При этом важно иметь в виду, что достичь последнего элемента при такой нумерации принципиально невозможно, иначе множество окажется конечным. Например, есть все основания считать множество всех звезд бесконечным, хотя многие из них имеют свое уникальное название. С другой стороны, множество всех возможных комбинаций из 8 символов, которые могут служить для ввода некоторого пароля, конечное, хотя и достаточно большое. Или, говоря строгим языком, это множество имеет конечную мощность.

Примечание

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

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

Хотя и существует некоторая неоднозначность в принятых обозначениях, кортеж из двух элементов удобно обозначать как <a1, a2>, из трех элементов — <a1, a2, a3> и т. д. При этом отдельные элементы могут принадлежать как одному и тому же множеству, так и различным множествам. Важно иметь в виду, что порядок выбора элементов для построения кортежей строго фиксирован для конкретной задачи. Речь идет о том, что первый элемент всегда выбирается из первого множества, второй — из второго, и т. д:

Отношение в этом случае будет характеризовать способ или семантику выбора отдельных элементов из одного или нескольких множеств для подобного упорядоченного списка. В этом смысле взаимосвязь является частным случаем отношения, о чем будет сказано в последующем. К сожалению, диаграммы Венна не предназначены для иллюстрации отношений в общем случае. Однако отношения послужили исходной идеей для развития другой теории, которая даже в своем названии несет отпечаток графической нотации, а именно — теории графов. В этой связи наиболее важным является тот факт, что теоретико-множественные отношения послужили также основой для разработки реляционной алгебры в теории реляционных баз данных. Развитие последней привело к тому, что в последние годы именно реляционные СУБД конкретных фирм доминируют на рынке соответствующего программного обеспечения.

Теория графов

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

Графом называется совокупность двух множеств: множества точек или вершин и множества соединяющих их линий или ребер. Формально граф задается в виде двух множеств: G=(V, Е), где V={v1v2, ..., vn} — множество вершин графа, а Е={е1, е2, ..., еm} — множество ребер графа. Натуральное число n определяет общее количество вершин конкретного графа, а натуральное число m — общее количество ребер графа. Следует заметить, в общем случае не все вершины графа могут соединяться между собой, что ставит в соответствие каждому графу некоторое бинарное отношение PQ, состоящее из всех пар вида <vi, vj>, где vi, vj = V. При этом пара <vi, vj> и, соответственно, пара <vj, vi> принадлежат отношению PG в том и только в том случае, если вершины vi и vj соединяются в графе G некоторым ребром ek=Е. Вершины графа изображаются точками, а ребра — отрезками прямых линий. Рядом с вершинами и ребрами записываются соответствующие номера или идентификаторы, позволяющие их идентифицировать однозначным образом.

Примечание

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

Ориентированный граф также задается в виде двух множеств G=(V, E), где V={v1, v2, ...,vn} — множество вершин графа, а E={е1, е2,...,еm] — множество дуг графа. Натуральное число n определяет общее количество вершин конкретного графа, а натуральное число m — общее количество дуг графа. При этом каждая дуга еk=Е ориентированного графа G имеет свое начало— некоторую единственную вершину vi=V и конец — некоторую единственную вершину vj=V, В отличие от ребра, дуга всегда имеет обозначение со стрелочкой, которая направлена к конечной вершине дуги. Множество дуг ставит в соответствие каждому ориентированному графу некоторое бинарное отношение PG, состоящее из всех пар вида <vi, vj>, где vi, vj=V. При этом пара <vi, vj> принадлежит отношению PG в том и только в том случае, если вершины vi и vj соединяются в графе G некоторой дугой еk=Е с началом в вершине viи концом в вершине vj.

Ниже представлены два примера конкретных графов (рис. 2.4). При этом первый из них (рис. 2.4, а) является неориентированным графом, а второй (рис. 2.4, б) — ориентированным графом. Как нетрудно заметить, для неориентированного графа ребро е1 соединяет вершины v1 и v2, ребро е2 — вершины v1 и v3, а ребро e3 — вершины v2 и v3 и т. д. Последнее ребро, e8, соединяет вершины v4 и v5, тем самым задается описание графа в целом. Других ребер данный граф не содержит, как не содержит других вершин, не изображенных на рисунке. Так, хотя ребра е6 и e7 визуально пересекаются, но точка их пересечения не является вершиной графа.

Для ориентированного графа (рис. 2.4, б) ситуация несколько иная. А именно, вершины v1 и v2 соединены дугой е1, для которой вершина v2 является началом дуги, а вершина v1 — концом этой дуги. Далее дуга е2 соединяет вершины v1 и v4, при этом началом дуги e2 является вершина v1, а концом — вершина v4.

Рис. 2.4. Примеры неориентированного (а) и ориентированного (б) графов

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

Важными понятиями теории графов являются понятия маршрута и пути, которые ассоциируются с последовательным перемещением от вершины к вершине по соединяющим их ребрам или дугам. Для неориентированного графа маршрут определяется как конечная или бесконечная упорядоченная последовательность ребер S=<, esl, es2, ..., esk>>, таких, что каждые два соседних ребра имеют общую вершину. Нас будут интересовать только конечные маршруты S=<es1, es2, ..., esk>, т. е. такие маршруты, которые состоят из конечного числа ребер. При этом ребро esl принято считать началом маршрута S, а ребро esk — концом маршрута S. Для ориентированного графа соответствующая последовательность дуг S=<es1, es2, ..., esk> называется ориентированным маршрутом, если две соседние дуги имеют общую вершину, которая является концом предыдущей и началом последующей дуги.

Примерами маршрутов для неориентированного графа (рис. 2.4, а) являются последовательности ребер: S1=<e1, e2 e5, e8>, S2=<e1, e2, е3, e1>, S3=<e3, e5, e8>. Если в маршруте не повторяются ни ребра, ни вершины, как в случае S1 и S3, то такой неориентированный маршрут называется простой цепью.

Примерами ориентированных маршрутов для графа (рис. 2.4, б) являются такие последовательности дуг: S1=<e2, e8, e5>, S2=<e3, e7, e6>, S3=<e8, e3, e7, e4, e8>. Если в ориентированном маршруте не повторяются ни ребра, ни вершины, как в случае S1 и S2, то такой ориентированный маршрут называется путем. Последнее понятие также иногда применяется для обозначения простой цепи в неориентированных графах и для определения специального класса графов, так называемых деревьев. В общем случае деревья служат для графического представления иерархических структур или иерархий, занимающих важное место в ООАП.

Деревом в теории графов называется такой граф D=<V, E>, между любыми двумя вершинами которого существует единственная простая цепь, т. е. неориентированный маршрут, у которого вершины и ребра не повторяются. Применительно к ориентированным графам соответствующее определение является более сложным, поскольку основывается на выделении некоторой специальной вершины v0, которая получила специальное название корневой вершины или просто — корня. В этом случае ориентированный граф D=<V, Е> называется ориентированным деревом или сокращенно — деревом, если между корнем дерева v0 и любой другой вершиной существует единственный путь, берущий начало в v0. Ниже представлены два примера деревьев: неориентированного дерева (рис. 2.5, а) и ориентированного дерева (рис. 2.5, б).

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

Рис. 2.5. Примеры неориентированного (а) и ориентированного (б) деревьев

Для случая ориентированного дерева (рис. 2.5, б) вершина v2 является единственным его корнем и имеет специальное обозначение v0. Единственность корня в ориентированном дереве следует из того факта, что ориентированный путь всегда имеет единственную вершину, которая является его началом. Поскольку в теории графов имеет значение только наличие или отсутствие связей между отдельными вершинами, деревья, как правило, изображаются специальным образом в виде иерархической структуры. При этом корень дерева изображается самой верхней вершиной в данной иерархии. Далее следуют вершины уровня 1, которые связаны с корнем одним ребром или одной дугой. Следующий уровень будет иметь номер 2, поскольку соответствующие вершины должны быть связаны с корнем двумя последовательными ребрами или дугами. Процесс построения иерархического дерева продолжается до тех пор, пока не будут рассмотрены вершины, которые не связаны с другими вершинами, кроме рассмотренных, или из которых не выходит ни одна дуга. В этом случае самые нижние вершины иногда называют листьями дерева. Важно иметь в виду, что в теории графов дерево "растет" вниз, а не вверх, как в реальной жизни.

Изображенные выше деревья (рис. 2.5) можно преобразовать к виду иерархий. Например, неориентированное дерево (рис. 2.5, а) может быть представлено в виде иерархического дерева следующим образом (рис. 2.6, а). В этом случае корнем иерархии является вершина v1. Ориентированное дерево (рис. 2.5, б) также может быть изображено в форме иерархического дерева (рис. 2.6, б), однако такое представление является единственным.

В первом случае (рис. 2.6, а) вершина v2 образует первый уровень иерархии, вершины v4 и v3 — второй уровень иерархии, вершина v5 — третий и последний уровень иерархии. При этом листьями данного неориентированного дерева являются вершины v3 и v5. Во втором случае (рис. 2.6, б) вершины v1 и v5 образуют первый уровень иерархии, вершины v4 и v6 — второй уровень иерархии, вершина v3 — третий и последний уровень иерархии. Листьями данного ориентированного дерева являются вершины v3 и v6.

Рис. 2.6. Иерархические схемы неориентированного дерева (а) и ориентированного дерева (б)

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

Семантические сети

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

В общем случае под семантической сетью понимают некоторый граф Gs= =(Vs, Es), в котором множество вершин Vs и множество ребер Es разделены на отдельные типы, обладающие специальной семантикой, характерной для той или иной предметной области. В данной ситуации множество вершин может соответствовать объектам или сущностям рассматриваемой предметной области и иметь вместо номеров вершин соответствующие явные имена этих сущностей. Подобные имена должны позволять однозначно идентифицировать соответствующие объекты, при этом общих формальных правил записи имен не существует. Множество ребер также делится на различные типы, которые соответствуют различным видам связей между сущностями рассматриваемой предметной области.

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

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

Примечание

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

В качестве конкретного варианта представления информации в виде семантической сети рассмотрим дальнейшее развитие примера с классом "Автомобиль" из главы 1. Фрагмент семантической сети, которая описывает иерархию классов данной предметной области, может быть изображен следующим образом (рис. 2.7). На данном рисунке отдельные вершины семантической сети изображаются прямоугольниками с закругленными концами и служат для условного обозначения классов данной предметной области. Соединяющие вершины ребра имеют вполне определенный смысл или семантику. А именно, они явно указывают, что вершина или класс, расположенные на рисунке ниже, являются подклассом того класса уровнем выше, с которым имеется связь в форме соединяющего их ребра.

Например, классы "Легковой автомобиль" и "Грузовой автомобиль" являются подклассами класса "Автомобиль", а классы "Модель ВАЗ-21083" и "Модель ВАЗ-21099" являются подклассами класса "Легковой автомобиль производства ВАЗ". Ребра или связи данной семантической сети имеют единственный тип, определяемый семантикой включения классов друг в друга. Поэтому никаких дополнительных обозначений они не содержат.

Рис 2.7. Фрагмент семантической сети для представления иерархии классов "Автомобиль"

Примечание

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

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

2.2. Диаграммы структурного системного анализа

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

В рамках данного направления программной инженерии принято рассматривать три графические нотации, получивших названия диаграмм: диаграммы "сущность-связь" (Entity-Relationship Diagrams, ERD), диаграммы функционального моделирования (Structured Analysis and Design Technique, SADT) и диаграммы потоков данных (Data Flow Diagrams, DFD).

Диаграммы "сущность-связь"

Данная нотация была предложена П. Ченом (P. Chen) в его известной работе 1976 года [17] и получила дальнейшее развитие в работах Р. Баркера [16] (R. Barker). Диаграммы "сущность-связь" (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают некоторый набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними, имеющих важное значение для разрабатываемой системы.

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

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

Рис. 2.8. Графические изображения для обозначения сущностей

Связь (relationship) определяется как отношение или некоторая ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения типа "отец-сын" или производственные отношения типа "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи (рис. 2.9).

Рис. 2.9. Графические изображения для обозначения связей

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

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

Рис. 2.10. Диаграмма "сущность-связь" для примера сотрудников некоторой компании

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

Рис. 2.11. Диаграмма "сущность-связь" для примера сотрудников, участвующих в работе над проектами

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

Рис. 2.12. Диаграмма "сущность-связь" для общего примера компании

Примечание

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

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

Диаграммы функционального моделирования

Начало разработки диаграмм функционального моделирования относится к середине 1960-х годов, когда Дуглас Т. Росс предложил специальную технику моделирования, получившую название SADT (Structured Analysis & Design Technique). Военно-воздушные силы США использовали методику SADT в качестве части своей программы интеграции компьютерных и промышленных технологий (Integrated Computer Aided Manufacturing, ICAM) и назвали ее IDEFO (Icam DEFinition). Целью программы ICAM было увеличение эффективности компьютерных технологий в сфере проектирования новых средств вооружений и ведения боевых действий. Одним из результатов этих исследований являлся вывод о том, что описательные языки не эффективны для документирования и моделирования процессов функционирования сложных систем. Подобные описания на естественном языке не обеспечивают требуемого уровня непротиворечивости и полноты, имеющих доминирующее значение при решении задач моделирования.

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

  • Нотация IDEF0 — для документирования процессов производства и отображения информации об использовании ресурсов на каждом из этапов проектирования систем.
  • Нотация IDEF1 — для документирования информации о производственном окружении систем.
  • Нотация IDEF2 — для документирования поведения системы во времени.
  • Нотация IDEF3 — специально для моделирования бизнес-процессов.

Нотация IDEF2 никогда не была полностью реализована. Нотация IDEF1 в 1985 году была расширена и переименована в IDEF1X. Методология IDEF-SADT, нашла применение в правительственных и коммерческих организациях, поскольку на тот период времени вполне удовлетворяла различным требованиям, предъявляемым к моделированию широкого класса систем.

В начале 1990 года специально образованная группа пользователей IDEF (IDEF Users Group), в сотрудничестве с Национальным институтом по стандартизации и технологии США (National Institutes for Standards and Technology, NIST), предприняла попытку создания стандарта для IDEFO и IDEF1X. Эта попытка оказалась успешной и завершилась принятием в 1993 году стандарта правительства США, известного как FIPS для данных двух технологий IDEFO и IDEF1X. В течение последующих лет этот стандарт продолжал активно развиваться и послужил основой для реализации в некоторых первых CASE-средствах.

Методология IDEF-SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели сиетемы какой-либо предметной области. Функциональная модель SADT отображает структуру процессов функционирования системы и ее отдельных подсистем, т. е. выполняемые ими действия и связи между этими действиями. Для этой цели строятся специальные модели, которые позволяют в наглядной форме представить последовательность определенных действий. Исходными строительными блоками любой модели IDEFO процесса являются деятельность (activity) и стрелки (arrows).

Рассмотрим кратко эти основные понятия методологии IDEF-SADT, которые используются при построении диаграмм функционального моделирования. Деятельность представляет собой некоторое действие или набор действий, которые имеют фиксированную цель и приводят к некоторому конечному результату. Иногда деятельность называют просто процессом. Модели IDEFO отслеживают различные виды деятельности системы, их описание и взаимодействие с другими процессами. На диаграммах деятельность или процесс изображается прямоугольником, который называется блоком. Стрелка служит для обозначения некоторого носителя или воздействия, которые обеспечивают перенос данных или объектов от одной деятельности к другой. Стрелки также необходимы для описания того, что именно производит деятельность и какие ресурсы она потребляет. Это так называемые роли стрелок — ICOM — сокращение первых букв от названий соответствующих стрелок IDEFO. При этом различают стрелки четырех видов:

  • I (Input) — вход, т. е. все, что поступает в процесс или потребляется процессом.
  • С (Control) — управление или ограничения на выполнение операций процесса.
  • О (Output) — выход или результат процесса.
  • М (Mechanism) — механизм, который используется для выполнения процесса.

Методология IDEFO однозначно определяет, каким образом изображаются на диаграммах стрелки каждого вида ICOM. Стрелка Вход (Input) выходит из левой стороны рамки рабочего поля и входит слева в прямоугольник процесса. Стрелка Управление (Control) входит и выходит сверху. Стрелка Выход (Output) выходит из правой стороны процесса и входит в правую сторону рамки. Стрелка Механизм (Mechanism) входит в прямоугольник процесса снизу. Таким образом, базовое представление процесса на диаграммах IDEFO имеет следующий вид (рис. 2.13).

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

Рис. 2.13. Обозначение процесса и стрелок ICOM на диаграммах IDEF0

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

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

Рис. 2.14. Пример исходной диаграммы IDEF-SADT для процесса оформления кредита в банке

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

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

Диаграммы потоков данных

Основой данной методологии графического моделирования информационных систем является специальная технология построения диаграмм потоков данных DFD. В разработке методологии DFD приняли участие многие аналитики, среди которых следует отметить Э. Йордона (Е. Yourdon). Он является автором одной из первых графических нотаций DFD [10]. В настоящее время наиболее распространенной является так называемая нотация Гейна-Сарсона (Gene-Sarson), основные элементы которой будут рассмотрены в этом разделе.

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

Основными компонентами диаграмм потоков данных являются:

  • внешние сущности
  • накопители данных или хранилища
  • процессы
  • потоки данных
  • системы/подсистемы

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

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

Рис. 2.15. Изображение внешней сущности на диаграмме потоков данных

Процесс представляет собой совокупность операций по преобразованию входных потоков данных в выходные в соответствии с определенным алгоритмом или правилом. Хотя физически процесс может быть реализован различными способами, наиболее часто подразумевается программная реализация процесса. Процесс на диаграмме потоков данных изображается прямоугольником с закругленными вершинами (рис. 2.16), разделенным на три секции или поля горизонтальными линиями. Поле номера процесса служит для идентификации последнего. В среднем поле указывается имя процесса. В качестве имени рекомендовано использовать глагол в неопределенной форме с необходимыми дополнениями. Нижнее поле содержит указание на способ физической реализации процесса.

Рис. 2.16. Изображение процесса на диаграмме потоков данных

Рис. 2.17. Изображение подсистемы на диаграмме потоков данных

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

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

Рис. 2.18. Изображение накопителя на диаграмме потоков данных

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

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

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

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

Рис. 2.19. Пример диаграммы DFD для процесса получения некоторой суммы наличными по кредитной карточке

2.3. Основные этапы развития UML

Отдельные языки объектно-ориентированного моделирования стали появляться в период между серединой 1970-х и концом 1980-х годов, когда различные исследователи и программисты предлагали свои подходы к ООАП. В период между 1989—1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50. Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных систем. Принятие отдельных методик и графических нотаций в качестве стандартов (IDEF0, IDEF1X) не смогло изменить сложившуюся ситуацию непримиримой конкуренции между ними в начале 90-х годов, которая тоже получила название "войны методов".

К середине 1990-х некоторые из методов были существенно улучшены и приобрели самостоятельное значение при решении различных задач ООАП. Наиболее известными в этот период становятся:

  • Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch Lite (позже — Booch'93).
  • Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique - ОМТ (позже - ОМТ-2).
  • Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software Engineering — OOSE.

Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП. Например, метод OOSE содержал средства представления вариантов использования, которые имеют существенное значение на этапе анализа требований в процессе проектирования бизнес-приложений. Метод ОМТ-2 наиболее подходил для анализа процессов обработки данных в информационных системах. Метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки различных программных систем.

История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекоб-сон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.

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

Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Дже-кобсон сформулировали следующие требования к языку моделирования. Он должен:

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

Разработка системы обозначений или нотации для ООАП оказалась непохожей на разработку нового языка программирования. Во-первых, необходимо было решить две проблемы:

  1. Должна ли данная нотация включать в себя спецификацию требований?
  2. Следует ли расширять данную нотацию до уровня языка визуального программирования?

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

В этот период поддержка разработки языка UML становится одной из целей консорциума OMG (Object Management Group). Хотя консорциум OMG был образован еще в 1989 году с целью разработки предложений по стандартизации объектных и компонентных технологий CORBA, язык UML приобрел статус второго стратегического направления в работе OMG. Именно в рамках OMG создается команда разработчиков под руководством Ричарда Соли, которая будет обеспечивать дальнейшую работу по унификации и стандартизации языка UML. В июне 1995 года OMG организовала совещание всех крупных специалистов и представителей входящих в консорциум компаний по методологиям ООАП, на котором впервые в международном масштабе была признана целесообразность поиска индустриальных стандартов в области языков моделирования под эгидой OMG.

Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов, содержащих описание собственно языка UML версии 0.9 (июнь 1996 г.) и версии 0.91 (октябрь 1996 г.). Имевшие статус запроса предложений RTP (Request For Proposals), эти документы послужили своеобразным катализатором для широкого обсуждения языка UML различными категориями специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения отдельными понятиями и конструкциями.

В это же время стало ясно, что некоторые компании и организации видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.

Примечание

Всеми партнерами консорциума осознается важность стандартизации языка UML, которая является необходимой основой для последующей разработки инструментальных CASE-средств. При этом разработка каждого стандарта в рамках консорциума OMG начинается с выпуска документа, называемого запросом предложений (Request For Proposals, RFP). Документы RFP в соответствии с установленной в OMG процедурой явно формулируют цели предстоящей разработки, требования, которым должны удовлетворять предложения, претендующие на стандартизацию, и объявляются сроки их представления. Отдельные RFP являются официальными документами, которыми руководствуются разработчики вариантов проектов соответствующих стандартов.

Инструментальные CASE-средства и диапазон их практического применения в большой степени зависят от удачного определения семантики и нотации соответствующего языка моделирования. Специфика языка UML заключается в том, что он определяет семантическую метамодель, а не модель конкретного интерфейса и способы представления или реализации компонентов.

Из более чем 800 компаний и организаций, входящих в настоящее время в состав консорциума OMG, особую роль продолжает играть Rational Software Corporation, которая стояла у истоков разработки языка UML. Эта компания разработала и выпустила в продажу одно из первых инструментальных CASE-средств Rational Rose 98, в котором был реализован язык UML.

В январе 1997 года целый ряд других компаний, среди которых были IBM, ObjecTime, Platinum Technology и некоторые другие, представили на рассмотрение OMG свои собственные ответы на запрос предложений RFP. В дальнейшем эти компании присоединились к партнерам UML, предлагая включить в язык UML некоторые свои идеи. В результате совместной работы с партнерами UML была предложена пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML 1.1 было уделено достижению большей ясности семантики языка по сравнению с UML 1.0, а также учету предложений новых партнеров. Эта версия языка была представлена на рассмотрение OMG и была одобрена и принята в качестве стандарта OMG в ноябре 1997. года.

В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках консорциума OMG. Соответствующая группа специалистов обеспечивает публикацию материалов, содержащих описание последующих версий языка UML и запросов предложений RFP по его стандартизации. Очередной этап развития данного языка закончился в марте 1999 года, когда консорциумом OMG было опубликовано описание языка UML 1.3 (alpha R5). Последней версией языка UML на момент написания книги является UML 1.3, которая описана в соответствующем документе — "OMG Unified Modeling Language Specification", опубликованном в июне 1999 года. История разработки и последующего развития языка UML графически представлена на рис. 2.20.

Рис. 2.20. История развития языка UML

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

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

В этой связи следует отметить внимание гиганта компьютерной индустрии компании Microsoft к технологии UML. Еще в октябре 1996 г. Microsoft и Rational Software Coiporation объявили о своем стратегическом партнерстве, которое, по их общему мнению, способно оказать решающее влияние на рынок средств объектно-ориентированной разработки программ. При этом Microsoft лицензировала у Rational Software некоторые технологии визуального моделирования, в результате чего был разработан Microsoft Visual Modeler for Visual Basic. В свою очередь Rational Software лицензировала у Microsoft Visual Basic и Microsoft Repositoiy, разрабатываемые вместе с Texas Instruments. При создании языка UML Microsoft внесла свой вклад в интеграцию UML со своими стандартами типа ActiveX и СОМ и в использование языка UML со своей технологией Microsoft Repository.

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

Уже в настоящее время разработаны средства визуального программирования на основе UML, обеспечивающие интеграцию, включая прямую и обратную генерацию кода программ, с наиболее распространенными языками и средами программирования, такими как MS Visual C++, Java, Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на очередные версии языка UML также окажут влияние и другие перспективные технологии и концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные методы. Язык UML может быть расширен без переопределения его ядра.

Подводя итог анализу методологии ООАП и исторических предпосылок появления UML, можно утверждать следующее. Имеются все основания предполагать, что в ближайшие годы язык UML в его современном виде станет основой для разработки и реализации во многих перспективных инструментальных средствах: в RAD-средствах визуального и имитационного моделирования, а также в CASE-средствах самого различного целевого назначения. Более того, заложенные в языке UML потенциальные возможности могут быть использованы не только для объектно-ориентированного моделирования систем, но и для представления знаний в интеллектуальных системах, которыми, по существу, станут перспективные сложные программно-технологические комплексы.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 3
Основные компоненты языка UML

  • 3.1. Назначение языка UML
  • 3.2. Общая структура языка UML
  • 3.3. Пакеты в языке UML
  • 3.4. Основные пакеты метамодели языка UML
    • Пакет Основные элементы
    • Пакет Элементы ядра
    • Пакет Вспомогательные элементы
    • Пакет Механизмы расширения
    • Пакет Типы данных
    • Пакет Элементы поведения
    • Пакет Общее поведение
    • Пакет Кооперации
    • Пакет Варианты использования
    • Пакет Автоматы
    • Пакет Общие механизмы
    • Пакет Управление моделями
  • 3.5. Специфика описания метамодели языка UML
  • 3.6. Особенности изображения диаграмм языка UML

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

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

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

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

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

Рис. 3.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе объектно-ориентированного анализа и проектирования

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

Примечание

Название "физическая модель" в терминологии ООАП и языка UML отличается от общепринятой трактовки этого термина в общей классификации моделей систем. В последнем случае под физической моделью системы понимают некоторую материальную конструкцию, обладающую свойствами подобия с формой оригинала. Примерами таких моделей могут служить модели технических систем (самолетов, кораблей), архитектурных сооружений (зданий, микрорайонов). Что касается использования этого термина в ООАП и языке UML, то здесь физическая модель отражает компонентный состав проектируемой системы с точки зрения ее реализации на некоторой технической базе и вычислительных платформах конкретных производителей.

3.1. Назначение языка UML

Язык UML предназначен для решения следующих задач:

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

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

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

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

  2. Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области.

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

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

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

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

Речь идет о том, что ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования. То есть, хотя отдельные понятия языка UML и связаны с последними очень тесно, их жесткая интерпретация в форме каких бы то ни было конструкций программирования не может быть признана корректной. Другими словами, разработчики из OMG считают необходимым свойством языка UML его контекстно-программную независимость.

С другой стороны, язык UML должен обладать потенциальной возможностью реализации своих конструкций на том или ином языке программирования. Конечно, в первую очередь имеются в виду языки, поддерживающие концепцию ООП, такие как C++, Java, Object Pascal. Именно это свойство языка UML делает его современным средством решения задач моделирования сложных систем. В то же время, предполагается, что для программной поддержки конструкций языка UML могут быть разработаны специальные инструментальные CASE-средства. Наличие последних имеет принципиальное значение для широкого распространения и использования языка UML.

  4. Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

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

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

  5. Поощрять развитие рынка объектных инструментальных средств.

Более 800 ведущих производителей программных и аппаратных средств, усилия которых сосредоточены в рамках OMG, видят перспективы развития современных информационных технологий и основу своего коммерческого успеха в широком продвижении на рынок инструментальных средств, поддерживающих объектные технологии. Говоря же об объектных технологиях, разработчики из OMG имеют в виду, прежде всего, совокупность технологических решений CORBA и UML. С этой точки зрения языку UML отводится роль базового средства для описания и документирования различных объектных компонентов CORBA.

  6. Способствовать распространению объектных технологий и соответствующих понятий ООАП.

Эта задача тесно связана с предыдущей и имеет с ней много общего. Если исключить из рассмотрения рекламные заявления разработчиков об исключительной гибкости и мощности языка UML, а попытаться составить объективную картину возможностей этого языка, то можно прийти к следующему заключению. Следует признать, что усилия.достаточно большой группы разработчиков были направлены на интеграцию в рамках языка UML многих известных техник визуального моделирования, которые успешно зарекомендовали себя на практике (см. главу 2). Хотя это привело к усложнению языка UML по сравнению с известными нотациями структурного системного анализа, платой за сложность являются действительно высокая гибкость и изобразительные возможности уже первых версий языка UML. В свою очередь, использование языка UML для решения всевозможных практических задач будет только способствовать его дальнейшему совершенствованию, а значит и дальнейшему развитию объектных технологий и практики ООАП.

  7. Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

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

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

Примечание

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

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

3.2. Общая структура языка UML

С самой общей точки зрения описание языка UML состоит из двух взаимодействующих частей, таких как:

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

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

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

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

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

  • Мета-метамодель
  • Метамодель
  • Модель
  • Объекты пользователя

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

Примечание

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

Метамодель является экземпляром или конкретизацией мета-метамодели. Главная задача этого уровня — определить язык для спецификации моделей. Данный уровень является более конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий. Все основные понятия языка UML — это понятия уровня метамодели. Примеры таких понятий — класс, атрибут, операция, компонент, ассоциация и многие другие. Именно рассмотрению семантики и графической нотации понятий уровня метамодели посвящена данная книга.

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

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

Конкретизация понятий модели происходит на уровне объектов. В настоящем контексте объект является экземпляром модели, поскольку содержит конкретную информацию относительно того, чему в действительности соответствуют те или иные понятия модели. Примером объекта может служить следующая запись в проектируемой базе данных: "Илья Петров, 30 лет, иллюзионист, ул. Невидимая, 10-20, 100-0000".

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

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

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

Примечание

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

3.3. Пакеты в языке UML

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

Примечание

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

Из главы 2 нам также известно, что для графического представления иерархий могут использоваться графы специального вида, которые называются деревьями (см. рис. 2.5Г2.6). Однако в языке UML эти графические обозначения настолько модифицированы, что соответствующие ассоциации с общетеоретическими понятиями могут представлять определенную трудность для начинающих разработчиков. Тем не менее, на протяжении всей книги подчеркивается важность умения ассоциировать специальные конструкции языка UML с соответствующими понятиями теории множеств и системного моделирования, что, в некотором смысле, формирует стиль мышления системного аналитика. В противном случае не исключены досадные ошибки не только на начальном этапе концептуализации предметной области, но и в процессе построений различных представлений систем.

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

Для графического изображения пакетов на диаграммах применяется специальный графический символ — большой прямоугольник с небольшим прямоугольником, присоединенным к левой части верхней стороны первого (рис. 3.2 а, б). Можно сказать, что визуально символ пакета напоминает пиктограмму папки в популярном графическом интерфейсе. Внутри большого прямоугольника может записываться информация, относящаяся к данному пакету. Если такой информации нет, то внутри большого прямоугольника записывается имя пакета, которое должно быть уникальным в пределах рассматриваемой модели (рис. 3.2, а). Если же такая информация имеется, то имя пакета записывается в верхнем маленьком прямоугольнике (рис. 3.2, б).

Рис. 3.2. Графическое изображение пакета в языке UML

Примечание

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

Перед именем пакета может помещаться строка текста, содержащая некоторое ключевое слово. Подобными ключевыми словами являются заранее определенные в языке UML слова, которые получили название стереотипов. Такими стереотипами для пакетов являются слова facade, framework, stub и topLevel. В качестве содержимого пакета могут выступать имена его отдельных элементов и их свойства, такие как видимость элементов за пределами пакета. Более подробно стереотипы и видимость элементов будут рассмотрены в последующих главах книги.

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

Одним из типов отношений между пакетами является отношение вложенности или включения пакетов друг в друга. С одной стороны, в языке UML это отношение может быть изображено без использования линий простым размещением одного пакета-прямоугольника внутри другого пакета-прямоугольника (рис. 3.3). Так, в данном случае пакет с именем ПакетЛ содержит в себе два подпакета: Пакет_2 и Пакет_3.

Рис. 3.3. Графическое изображение вложенности пакетов друг в друга

Рис. 3.4. Графическое изображение вложенности пакетов друг в друга с помощью явной визуализации отношения включения

С другой стороны, это же отношение может быть изображено с помощью отрезков линий аналогично графическому представлению дерева. В этом случае наиболее общий пакет (метапакет или контейнер) изображается в верхней части рисунка, а его подпакеты — уровнем ниже. Метапакет соединяется с подпакетами сплошной линией, на конце которой, примыкающей к метапакету, изображается специальный символ © (знак плюс в кружочке). Этот символ означает, что подпакеты являются "собственностью" или частью контейнера, и, кроме этих подпакетов, контейнер не содержит никаких других подпакетов. Рассмотренный выше пример (рис. 3.3) может быть представлен с помощью явной визуализации отношения включения (рис. 3.4).

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

3.4. Основные пакеты метамодели языка UML

Возвращаясь к рассмотрению языка UML, напомним, что основой его представления на метамодельном уровне является описание трех его логических блоков или пакетов: Основные элементы, Элементы поведения и Общие механизмы (рис. 3.5).

Эти пакеты в свою очередь делятся на отдельные подпакеты. Например, пакет Основные элементы состоит из подпакетов: Элементы ядра, Вспомогательные элементы, Механизмы расширения и типы данных (рис. 3.6). При этом пакет Элементы ядра описывает базовые понятия и принципы включения в структуру метамодели основных понятий языка, таких как метаклассы, метаассоциации и метаатрибуты. Пакет Вспомогательные элементы определяет дополнительные конструкции, которые расширяют базовые элементы для описания зависимостей, шаблонов, физических структур и элементов представлений. Пакет Механизмы расширения задает правила уточнения и расширения семантики базовых элементов моделей. Пакет Типы данных определяет основные структуры данных для языка UML.

Рис. 3.5. Основные пакеты метамодели языка UML

Рис. 3.6. Подпакеты пакета Основные элементы языка UML

Пакет Основные элементы

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

Пакет Элементы ядра

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

Примечание

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

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

В этот пакет входят основные метаклассы языка UML: класс (Class), атрибут (Attribute), ассоциациях (Association), ассоциация-класс (AssociationClass), конец ассоциации (AssociationEnd), свойство поведения (BehavioralFeature), классификатор (Classifier), ограничение (Constraint), тип данных (DataType), зависимость (Dependency), элемент (Element), право на элемент (ElementOwnership), свойство (Feature), обобщение (Generalization), элемент отношения обобщения (GeneralizableElement), интерфейс (Interface), метод (Method), элемент модели (ModelElement), пространство имен (Namespace), операция (Operation), параметр (Parameter), структурное свойство (StructuralFeature), правила правильного построения выражений (Well-formedness rules).

Пакет Вспомогательные элементы

Пакет Вспомогательные элементы является подпакетом пакета Основные элементы и специфицирует дополнительные конструкции языка UML, которые расширяют пакет Элементы ядра. Вспомогательные элементы обеспечивают понятийный базис для зависимостей, шаблонов, физических структур и элементов представлений. В этот пакет входят следующие метаклассы: связывание (Binding), комментарий (Comment), компонент (Component), узел (Node), презентация (Presentation), уточнение (Refinement), цепочка зависимостей (Trace), потребление (Usage), элемент представления (ViewElement), зависимость (Dependency), элемент модели (ModelElement), правила правильного построения выражений (Well-formedness rules). При этом три последних метакласса взяты из пакета Элементы ядра и используются для спецификации остальных.

Примечание

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

Пакет Механизмы расширения

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

Для этой цели в языке UML предусмотрены три механизма расширения, которые могут использоваться совместно или раздельно для определения новых элементов модели с отличающимися семантикой, нотацией и свойствами от специфицированных в метамодели языка UML элементов. Такими механизмами являются: ограничение (Constraint), стереотип (Stereotype) и помеченное значение (TaggedValue).

Таким образом, механизмы расширения языка UML предназначены для выполнения следующих задач:

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

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

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

Пакет Типы данных

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

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

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

Для определения различных типов данных в языке UML используются как простые конструкции: целое число (Integer), строка (String), имя (Name), Булев (Boolean), время (Time), кратность (Multiplicity), тип видимости (VisibilityKind), диапазон кратности (MultiplicityRange), так и более сложные: выражение (Expression), булевское выражение (BooleanExpression), тип агрегирования (AggregationKind), тип изменения (ChangeableKind), геометрия (Geometry), отображение (Mapping), выражение-процедура (ProcedureExpression), тип псевдосостояния (PseudostateKind), выражение времени (TimeExpression), непрерываемый (Uninterpreted).

Пакет Элементы поведения

Этот пакет является самостоятельной компонентой языка UML и, как следует из его названия, специфицирует динамику поведения в нотации UML. Пакет Элементы поведения состоит из четырех подпакетов: Общее поведение, Кооперации, Варианты использования и Автоматы (рис. 3.7). Ниже дается краткая характеристика каждого из этих подпакетов.

Рис. 3.7. Подпакеты пакета Элементы поведения языка UML

Пакет Общее поведение

Пакет Общее поведение является наиболее фундаментальным из всех подпакетов и определяет базовые понятия ядра, необходимые для всех элементов поведения. В этом пакете специфицирована семантика для динамических элементов, которые включены в другие подпакеты элементов поведения. В пакет Общее поведение входит достаточно большое число элементов, таких как объект (Object), действие (Action), последовательность действий (ActionSequence), аргумент (Argument), экземпляр (Instance), исключение (Exception), связь (Link), сигнал (Signal), значение данных (DataValue), связь атрибутов (AttributeLink), действие вызова (CallAction), действие создания (CreateAction), действие уничтожения (DestroyAction).

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

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

Пакет Кооперации

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

В частности, в пакет Кооперации входят элементы: кооперация (Collaboration), взаимодействие (Interaction), сообщение (Message), роль ассоциации (AssociationRole), роль классификатора (ClassifierRole), роль конца ассоциации (AssociationEndRole). Как можно догадаться из названия пакета, его элементы непосредственно используются при построении диаграмм кооперации. Понятие кооперации имеет важное значение для представления взаимодействия элементов модели с точки зрения классификаторов и ассоциаций. Особенности их применения будут более детально рассмотрены при изучении диаграммы кооперации (см. главу 9).

Пакет Варианты использования

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

Примечание

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

В пакет Варианты использования кроме уже упомянутых элементов актер (Actor) и вариант использования (UseCase) входят: расширение (Extension), точка расширения (ExtensionPoint), включение (Include) и экземпляр варианта использования (UseCaselnstance). Более подробно некоторые из этих понятий будут рассмотрены при описании диаграмм вариантов использования (см. главу 4).

Пакет Автоматы

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

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

В пакет Автоматы входят элементы: состояние (State), переход (Transition), событие (Event), автомат (StateMachine), простое состояние (SimpleState), составное состояние CompositeState, псевдосостояние (PseudoState), конечное состояние (FinalState) и некоторые другие.

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

Более подробно понятия этого пакета будут рассмотрены при изучении диаграмм состояний (см. главу 6).

Пакет Общие механизмы

В этом пакете определены общие механизмы, которые применимы ко всем моделям UML. Пакет состоит из единственного подпакета управления моделями (рис. 3.8). Этот подпакет служит для спецификации способов организации элементов в модели, пакеты и подсистемы. Кратко рассмотрим основные особенности данного подпакета.

Рис. 3.8. Состав пакета Общие механизмы

Пакет Управление моделями

Пакет Управление моделями (Model Management) специфицирует базовые элементы языка UML, которые необходимы для формирования всех модельных представлений. Именно в нем определяется семантика модели (Model), пакета (Package) и подсистемы (Subsystem). Эти элементы служат своеобразными контейнерами для группировки других элементов модели.

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

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

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

Подсистема есть просто группировка элементов модели, которые специфицируют некоторое простейшее поведение физической системы. В метамоде-ли UML подсистема является подклассом как пакета, так и классификатора. Элементы подсистемы делятся на две части — спецификацию поведения и его реализацию.

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

Рис. 3.9. Графическое изображение подсистемы в языке UML

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

3.5. Специфика описания метамодели языка UML

Метамодель языка UML описывается на некотором полуформальном языке с использованием трех видов представлений:

  • Абстрактного синтаксиса
  • Правил правильного построения выражений
  • Семантики

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

Правила правильного построения выражений используются для задания дополнительных ограничений или свойств, которыми должны обладать те или иные компоненты модели. Поскольку исходным понятием ООП является понятие класса, его общими свойствами должны обладать все экземпляры, которые в этом смысле должны быть инвариантны друг другу. Для задания этих инвариантных свойств классов и отношений необходимо использовать специальные выражения некоторого формального языка, в рамках UML получившего название языка объектных ограничений (Object Constraint Language, ОСЬ). Хотя язык ОСЬ и использует естественный язык для формулировки правил правильного построения выражений, особенности его применения являются темой самостоятельного обсуждения. Основные особенности языка ОСЬ рассмотрены в приложении.

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

Сложность описания семантики языка UML вытекает из этой двойственности понятий. Здесь мы должны придерживаться традиционных правил изложения, поскольку понимание семантики носит индуктивный характер и требует для своей интерпретации примеров уровня модели и объекта. Иллюстрация абстрактных понятий на примере конкретных свойств и отношений, а также их значений позволяет акцентировать внимание на общих инвариантах этих понятий, что совершенно необходимо для понимания их семантики.

Примечание

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

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

Для придания формального характера моделям UML использование естественного языка должно строго соответствовать определенным правилам. Например, описание семантики языка UML может включать в себя фразы типа "Сущность А обладает способностью" или "Сущность Б есть сущность В". В каждом из этих случаев мы будем понимать смысл фраз, руководствуясь традиционным пониманием предложений русского языка. Однако этого может оказаться недостаточно для более формального представления знаний о рассматриваемых сущностях. Тогда необходимо дополнительно специфицировать семантику этих простых фраз, для чего рекомендуется использовать следующие правила:

  • Явно указывать в тексте экземпляр некоторого метакласса. Речь идет о том, что в естественной речи мы часто опускаем слово "пример" или "экземпляр", говоря просто "класс". Так, фразу "Атрибут возраст класса сотрудник имеет значение 30 лет" следует записать более точно, а именно: "Атрибут возраст экземпляра класса сотрудник имеет значение 30 лет".
  • В каждый момент времени используется только то значение слова, которое приписано имени соответствующей конструкции языка UML. Все дополнительные особенности семантики должны быть указаны явным образом без каких бы то ни было неявных предположений.
  • Термины языка UML могут включать только один из допустимых префиксов, таких как под-, супер- или мета-. При этом сам термин с префиксом записывается одним словом.

В дополнение к этому будут использоваться следующие правила выделения текста:

  • Если используются ссылки на конструкции языка UML, а не на их представления в метамодели, следует применять обычный текст без какого бы то ни было выделения.
  • Имена метаклассов являются элементом нотации языка UML и представляют собой существительное и, возможно, присоединенное к нему прилагательное. В этом случае имя метакласса на английском записывается одним словом с выделением каждой составной части имени заглавной буквой (например, ModelElement, StructuralFeature).
  • Имена метаассоциаций и ассоциаций классов записываются аналогичным образом (например, ElementReference).
  • Имена других элементов языка UML также записываются одним словом, но должны начинаться с маленькой буквы (например, ownedElement, allContents).
  • Имена метаатрибутов, которые принимают булевы значения, всегда начинаются с префикса "is" (например, isAbstract).
  • Перечислимые типы должны всегда заканчиваться словом "Kind" (например, AggregationKind).
  • При ссылках в тексте на метаклассы, метаассоциаций, метаатрибуты и т. д. должны всегда использоваться в точности те их имена, которые указаны в модели.
  • Имена стандартных обозначений (стереотипов) заключаются в кавычки и начинаются со строчной буквы (например, "type").

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

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

Примечание

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

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

  • Диаграмма вариантов использования (use case diagram)
  • Диаграмма классов (class diagram)
  • Диаграммы поведения (behavior diagrams)
    • Диаграмма состояний (statechart diagram)
    • Диаграмма деятельности (activity diagram)
    • Диаграммы взаимодействия (interaction diagrams)
      • Диаграмма последовательности (sequence diagram)
      • Диаграмма кооперации (collaboration diagram)
  • Диаграммы реализации (implementation diagrams)
    • Диаграмма компонентов (component diagram)
    • Диаграмма развертывания (deployment diagram)

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

  1. Диаграмма вариантов использования (см. главу 4).
  2. Диаграмма классов (см. главу 5).
  3. Диаграмма состояний (см. главу 6).
  4. Диаграмма деятельности (см. главу 7).
  5. Диаграмма последовательности (см. главу 8).
  6. Диаграмма кооперации (см. главу 9). 1. Диаграмма компонентов (см. главу 10). 8. Диаграмма развертывания (см. главу 11).

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

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

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

Рис. 3.10. Интегрированная модель сложной системы в нотации UML

Примечание

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

3.6. Особенности изображения диаграмм языка UML

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

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

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

Примечание

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

Таким образом, в языке UML используется четыре основных вида графических конструкций:

  • Значки или пиктограммы. Значок представляет собой графическую фигуру фиксированного размера и формы. Она не может увеличивать свои размеры, чтобы разместить внутри себя дополнительные символы. Значки могут размещаться как внутри других графических конструкций, так и вне их. Примерами значков могут служить окончания связей элементов диаграмм или некоторые другие дополнительные обозначения (украшения).
  • Графические символы на плоскости. Такие двумерные символы изображаются с помощью некоторых геометрических фигур и могут иметь различную высоту и ширину с целью размещения внутри этих фигур других конструкций языка UML. Наиболее часто внутри таких символов помещаются строки текста, которые уточняют семантику или фиксируют отдельные свойства соответствующих элементов языка UML. Информация, содержащаяся внутри фигур, имеет важное значение для конкретной модели проектируемой системы, поскольку регламентирует реализацию соответствующих элементов в программном коде.
  • Пути, которые представляют собой последовательности из отрезков линий, соединяющих отдельные графические символы. При этом концевые точки отрезков линий должны обязательно соприкасаться с геометрическими фигурами, служащими для обозначения вершин диаграмм, как принято в теории графов (см. главу 2). С концептуальной точки зрения путям в языке UML придается особое значение, поскольку они являются простыми топологическими сущностями. С другой стороны, отдельные части пути или сегменты могут не существовать сами по себе вне содержащего их пути. Пути всегда соприкасаются с другими графическими символами на обеих границах соответствующих отрезков линий. Другими словами, пути не могут обрываться на диаграмме линией, которая не соприкасается ни с одним графическим символом. Как отмечалось выше, пути могут иметь в качестве окончания или терминатора специальную графическую фигуру — значок, который изображается на одном из концов линий, являющихся сегментами этого пути.
  • Строки текста. Служат для представления различных видов информации в некоторой грамматической форме. Предполагается, что каждое использование строки текста должно соответствовать синтаксису в нотации языка UML, посредством которого может быть реализован грамматический разбор этой строки. Последний необходим для получения полной информации о модели. Например, строки текста в различных секциях обозначения класса могут соответствовать атрибутам этого класса или его операциям. На использование строк накладывается важное условие — семантика всех допустимых символов должна быть заранее определена в языке UML или служить предметом его расширения в конкретной модели.

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

  • Каждая диаграмма должна служить законченным представлением соответствующего фрагмента моделируемой предметной области. Речь идет о том, что в процессе разработки диаграммы необходимо учесть все сущности, важные с точки зрения контекста данной модели и диаграммы. Отсутствие тех или иных элементов на диаграмме служит признаком неполноты модели и может потребовать ее последующей доработки.
  • Все сущности на диаграмме модели должны быть одного концептуального уровня. Здесь имеется в виду согласованность не только имен одинаковых элементов, но и возможность вложения отдельных диаграмм друг в друга для достижения полноты представлений. В случае достаточно сложных моделей систем желательно придерживаться стратегии последовательного уточнения или детализации отдельных диаграмм.
  • Вся информация о сущностях должна быть явно представлена на диаграммах. Речь идет о том, что, хотя в языке UML при отсутствии некоторых символов на диаграмме могут быть использованы их значения по умолчанию (например, в случае неявного указания видимости атрибутов и операций классов), необходимо стремиться к явному указанию свойств всех элементов диаграмм.
  • Диаграммы не должны содержать противоречивой информации. Противоречивость модели может служить причиной серьезнейших проблем при ее реализации и последующем использовании на практике. Например, наличие замкнутых путей при изображении отношений агрегирования или композиции приводит к ошибкам в программном коде, который будет реализовывать соответствующие классы. Наличие элементов с одинаковыми именами и различными атрибутами свойств в одном пространстве имен также приводит к неоднозначной интерпретации и может служить источником проблем.

Примечание

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

  • Диаграммы не следует перегружать текстовой информацией. Принято считать, что визуализация модели является наиболее эффективной, если она содержит минимум пояснительного текста. Как правило, наличие больших фрагментов развернутого текста служит признаком недостаточной проработанности модели или ее неоднородности, когда в рамках одной модели представляется различная по характеру информация. Поскольку общая декомпозиция модели на отдельные типы диаграмм способна удовлетворить самые детальные представления разработчиков о системе, важно уметь правильно отображать те или иные сущности и аспекты моделирования в соответствующие элементы канонических диаграмм.
  • Каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов. Любые пояснительные тексты, которые не являются собственными элементами диаграммы (например, комментариями), не должны приниматься во внимание разработчиками. В то же время отдельные достаточно общие фрагменты диаграмм могут уточняться или детализироваться на других диаграммах этого же типа, образуя вложенные или подчиненные диаграммы. Таким образом, модель системы на языке UML представляет собой пакет иерархически вложенных диаграмм, детализация которых должна быть достаточной для последующей генерации программного кода, реализующего проект соответствующей системы.
  • Количество типов диаграмм для конкретной модели приложения не является строго фиксированным. Речь идет о том, что для простых приложений нет необходимости строить все без исключения типы диаграмм. Некоторые из них могут просто отсутствовать в проекте системы, и этот факт не будет считаться ошибкой разработчика. Например, модель системы может не содержать диаграмму развертывания для приложения, выполняемого локально на компьютере пользователя. Важно понимать, что перечень диаграмм зависит от специфики конкретного проекта системы.

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

Примечание

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

Процесс построения отдельных типов диаграмм имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООАП в контексте языка UML получил специальное название — рациональный унифицированный процесс (Rational Unified Process, RUP). Концепция RUP и основные его элементы разработаны А. Джекобсоном в ходе его работы над языком UML [18].

Примечание

При дословном переводе термина RUP теряется некоторая дополнительная семантическая окраска, связанная с двусмысленным толкованием английского Rational. Речь идет о другом варианте перевода — унифицированный процесс от фирмы Rational Software, сотрудниками которой являются с некоторых пор его разработчики, включая упомянутого выше А. Джекобсона.

Суть концепции RUP заключается в последовательной декомпозиции или разбиении процесса ООАП на отдельные этапы, на каждом из которых осуществляется разработка соответствующих типов канонических диаграмм модели системы. При этом на начальных этапах RUP строятся логические представления статической модели структуры системы, затем — логические представления модели поведения, и лишь после этого — физические представления модели системы. Как нетрудно заметить, в результате RUP должны быть построены канонические диаграммы на языке UML, при этом последовательность их разработки в основном совпадает с их последовательной нумерацией. Таким образом, порядок изложения канонических диаграмм в части II книги не является случайным, а определяется общими рекомендациями рационального унифицированного процесса.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 4
Диаграмма вариантов использования (use case diagram)

  • 4.1. Вариант использования
  • 4.2. Актеры
  • 4.3. Интерфейсы
  • 4.4. Примечания
  • 4.5. Отношения на диаграмме вариантов использования
    • Отношение ассоциации
    • Отношение расширения
    • Отношение обобщения
    • Отношение включения
  • 4.6. Пример построения диаграммы вариантов использования
  • 4.7. Рекомендации по разработке диаграмм вариантов использования

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

Разработка диаграммы вариантов использования преследует цели:

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.

Примечание

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

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

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

4.1. Вариант использования

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

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 4.1).

Рис. 4.1. Графическое обозначение варианта использования

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

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

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

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

Примечание

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

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

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

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

4.2. Актеры

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

Рис. 4.2. Графическое обозначение актера

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

Примечание

Имя актера должно быть достаточно информативным с точки зрения семантики. Вполне подходят для этой цели наименования должностей в компании (например, продавец, кассир, менеджер, президент). Не рекомендуется давать актерам имена собственные (например, "О.Бендер") или моделей конкретных устройств (например, "маршрутизатор Cisco 3640"), даже если это с очевидностью следует из контекста проекта. Дело в том, что одно и то же лицо может выступать в нескольких ролях и, соответственно, обращаться к различным сервисам системы. Например, посетитель банка может являться как потенциальным клиентом, и тогда он востребует один из его сервисов, а может быть и налоговым инспектором или следователем прокуратуры. Сервис для последнего может быть совершенно исключительным по своему характеру.

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

Примечание

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

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

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

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

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

4.3. Интерфейсы

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

На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом с которым записывается его имя (рис. 4.3, а). В качестве имени может быть существительное, которое характеризует соответствующую информацию или сервис (например, "датчик", "сирена", "видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода", "устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно начинаться с заглавной буквы I, например, ISecurelnformation, ISensor (рис. 4.3, б).

Рис. 4.3. Графическое изображение интерфейсов на диаграммах вариантов использования

Примечание

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

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

Рис. 4.4. Графическое изображение взаимосвязей интерфейсов с вариантами использования

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

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

4.4. Примечания

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

Графически примечания обозначаются прямоугольником с "загнутым" верхним правым уголком (рис. 4.5). Внутри прямоугольника содержится текст примечания. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся, соответственно, несколько линий. Разумеется, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах.

Рис. 4.5. Примеры примечаний в языке UML

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

4.5. Отношения на диаграмме вариантов использования

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

  • Отношение ассоциации (association relationship)
  • Отношение расширения (extend relationship)
  • Отношение обобщения (generalization relationship)
  • Отношение включения (include relationship)

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

Отношение ассоциации

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

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

Рис. 4.6. Пример графического представления отношения ассоциации между актером и вариантом использования

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

Примечание

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

Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации:

  • Целое неотрицательное число (включая цифру 0). Предназначено для указания кратности, которая является строго фиксированной для элемента соответствующей ассоциации. В этом случае количество экземпляров актеров или вариантов использования, которые могут выступать в качестве элементов отношения ассоциации, в точности равно указанному числу.

Примером этой формы записи кратности ассоциации является указание кратности "1" для актера "Клиент банка" (рис. 4.6). Эта запись означает, что каждый экземпляр варианта использования "Оформить кредит для клиента банка" может иметь в качестве своего элемента единственный экземпляр актера "Клиент банка". Другими словами, при оформлении кредита в банке необходимо иметь в виду, что каждый конкретный кредит оформляется на единственного клиента этого банка.

  • Два целых неотрицательных числа, разделенные двумя точками и записанные в виде: "первое число .. второе число". Данная запись в языке UML соответствует нотации для множества или интервала целых чисел, которая применяется в некоторых языках программирования для обозначения границ массива элементов. Эту запись следует понимать как множество целых неотрицательных чисел, следующих в последовательно возрастающем порядке:

{первое_число, первое_число+1, первое_число+2, ..., второе_число]. Очевидно, что первое число должно быть строго меньше второго числа в арифметическом смысле, при этом первое число может быть равно 0.

Пример такой формы записи кратности ассоциации — "1..5". Эта запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из множества целых чисел {1, 2, 3, 4, 5}. Эта ситуация может иметь место, например, в случае рассмотрения в качестве актера — клиента банка, а в качестве варианта использования — процедуру открытия счета в банке. При этом количество отдельных счетов каждого клиента в данном банке, исходя из некоторых дополнительных соображений, может быть не больше 5. Эти дополнительные соображения как раз и являются внешними требованиями по отношению к проектируемой системе и определяются ее заказчиком на начальных этапах ООАП.

  • Два символа, разделенные двумя точками. При этом первый из них является целым неотрицательным числом или 0, а второй — специальным символом "*". Здесь символ "*"обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации.

Пример такой формы записи кратности ассоциации — "2..*". Запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из подмножества натуральных чисел: {2, 3, 4}.

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

В качестве примера этой записи можно привести кратность отношения ассоциации для варианта использования "Оформить кредит для клиента банка" (рис. 4.6). Здесь кратность "*" означает, что каждый отдельный клиент банка может оформить для себя несколько кредитов, при этом их общее число заранее неизвестно и ничем не ограничивается. При этом некоторые клиенты могут совсем не иметь оформленных на свое имя кредитов (вариант значения 0).

Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1.

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

Отношение расширения

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

Отношение расширения между вариантами использования обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет"), как показано на рис. 4.7.

Рис. 4.7. Пример графического изображения отношения расширения между вариантами использования

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

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

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

В представленном выше примере (рис. 4.7) при оформлении заказа на приобретение товара только в некоторых случаях может потребоваться предоставление клиенту каталога всех товаров. При этом условием расширения является запрос от клиента на получение каталога товаров. Очевидно, что после получения каталога клиенту необходимо некоторое время на его изучение, в течение которого оформление заказа приостанавливается. После ознакомления с каталогом клиент решает либо в пользу выбора отдельного товара, либо отказа от покупки вообще. Сервис или вариант использования "Оформить заказ на приобретение товара" может отреагировать на выбор клиента уже после того, как клиент получит для ознакомления каталог товаров.

Рис. 4.8. Графическое изображение отношения расширения с примечаниями условий выполнения вариантов использования

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

Отношение обобщения

Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А — потомком по отношению к варианту использования В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (рис. 4.9). Эта линия со стрелкой имеет специальное название — стрелка "обобщение".

Рис. 4.9. Пример графического изображения отношения обобщения между вариантами использования

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

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

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

Рис. 4.10. Пример графического изображения отношения обобщения между актерами

Отношение включения

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

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

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

Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант отношения зависимости), направленной от базового варианта использования к включаемому. При этом данная линия со стрелкой помечается ключевым словом "include" ("включает"), как показано на рис. 4.11.

Рис. 4.11. Пример графического изображения отношения включения между вариантами использования

Примечание

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

4.6. Пример построения диаграммы вариантов использования

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

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

Рис. 4.12. Исходная диаграмма вариантов использования для примера разработки системы продажи товаров по каталогу

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

Примечание

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

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

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

Полученная в результате последующей детализации уточненная диаграмма вариантов использования будет содержать 5 вариантов использования и 2 актеров (рис. 4.13), между которыми установлены отношения включения и расширения.

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

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

С одной стороны, детализация может быть выполнена на основе установления дополнительных отношений типа отношения "обобщение-специализация" для уже имеющихся компонентов диаграммы вариантов использования. Так, в рамках рассматриваемой системы продажи товаров может иметь самостоятельное значение и специфические особенности отдельная категория товаров — компьютеры. В этом случае диаграмма может быть дополнена вариантом использования "Оформить заказ на покупку компьютера" и актерами "Покупатель компьютера" и "Продавец компьютеров", которые связаны с соответствующими компонентами диаграммы отношением обобщения (рис. 4.14).

Уточненный таким способом вариант диаграммы вариантов использования содержит одну важную особенность, которую необходимо отметить. А именно, хотя на данной диаграмме (рис. 4.14) отсутствуют изображения линий отношения ассоциации между актером "Продавец компьютеров" и вариантом использования "Оформить заказ на покупку компьютера", а также между актером "Покупатель компьютера" и вариантом использования "Оформить заказ на покупку компьютера", наличие отношения обобщения между соответствующими компонентами позволяет им наследовать отношение ассоциации от своих предков. Поскольку принцип наследования является одним из фундаментальных принципов объектно-ориентированного программирования, в нашем примере можно с уверенностью утверждать, что эти линии

отношения ассоциации с соответствующими кратностями присутствуют на данной диаграмме в скрытом виде.

Рис. 4.14. Один из вариантов последующего уточнения диаграммы вариантов использования для примера рассматриваемой системы продажи

Для пояснения изложенного можно привести фрагмент диаграммы вариантов использования для рассмотренного примера, на котором явно указаны отношения ассоциации между дочерними компонентами (рис. 4.15). Данное изображение фрагмента диаграммы приводится с методической целью, при этом остальные компоненты диаграммы, которые остались без изменений, условно отмечены многоточием.

Рис. 4.15. Фрагмент диаграммы вариантов использования, который в неявном виде присутствует на уточненной диаграмме с отношением ассоциации между отдельными компонентами

Примечание

Строго говоря, приведенное выше изображение фрагмента диаграммы не является допустимым с точки зрения нотации языка UML Причиной этого следует считать многоточие, которое не может быть использовано в подобной интерпретации. Тем не менее, данное изображение иллюстрирует основные идеи наследования свойств и поведения, которые неявно могут присутствовать в графических моделях сложных систем. С другой стороны, следует всегда помнить, что эта информация является избыточной с точки зрения семантики языка UML, а значит может быть опущена, что и было сделано на предыдущей диаграмме (см. рис. 4.14).

Второе из основных направлений детализации диаграмм вариантов использования связано с последующей структуризацией ее отдельных компонентов в форме элементов других диаграмм. Например, конкретные особенности реализации вариантов использования в терминах взаимодействующих объектов, определенных в виде классов данной сущности, могут быть заданы на диаграмме кооперации. Указанное направление отражает основные особенности ООАП применительно к их реализации в языке UML. Эти особенности являются предметом рассмотрения во всех последующих главах книги.

Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого — представить совокупность требований к поведению проектируемой системы. Спецификация требований к проектируемой системе в форме диаграммы вариантов использования представляет собой самостоятельную модель, которая в языке UML получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel".

В последующем все заданные в этой модели требования представляются в виде общей модели системы, которая состоит из пакета Системы. Последний в свою очередь может представлять собой иерархию пакетов, на самом верхнем уровне которых содержится множество классов модели проектируемой системы. Если же пакет системы со стандартным именем "topLevel Package" является подсистемой, то ее абстрактное поведение в точности такое же, как и у исходной системы.

4.7. Рекомендации по разработке диаграмм вариантов использования

Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе с помощью понятий соответствующего пакета и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность. Рекомендуемое общее количество актеров в модели — не более 20, а вариантов использования — не более 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм.

Семантика построения диаграммы вариантов использования должна определяться следующими особенностями рассмотренных выше элементов модели. Отдельный экземпляр варианта использования по своему содержанию является выполнением последовательности действий, которая инициализируется посредством экземпляра сообщения от экземпляра актера. В качестве отклика или ответной реакции на сообщение актера экземпляр варианта использования выполняет последовательность действий, установленную для данного варианта использования. Экземпляры актеров могут генерировать новые экземпляры сообщений для экземпляров вариантов использования.

Подобное взаимодействие будет продолжаться до тех пор, пока не закончится выполнение требуемой последовательности действий экземпляром варианта использования, и соответствующий экземпляр актера (и никакой другой) не получит требуемый экземпляр сервиса. Окончание взаимодействия означает отсутствие инициализации экземпляров сообщений от экземпляров актеров для соответствующих экземпляров вариантов использования.

Варианты использования могут быть специфицированы в виде текста, а в последующем — с помощью операций и методов вместе с атрибутами, в виде графа деятельности, посредством автомата или любого другого механизма описания поведения, включающего предусловия и постусловия. Взаимодействие между вариантами использования и актерами может уточняться на диаграмме кооперации, когда описываются взаимосвязи между сущностью, содержащей эти варианты использования, и окружением или внешней средой этой сущности.

В случае, когда для представления иерархической структуры проектируемой системы используются подсистемы, система может быть определена в виде вариантов использования на всех уровнях. Отдельные подсистемы или классы могут выступать в роли таких вариантов использования. При этом вариант, соответствующий некоторому из этих элементов, в последующем может уточняться множеством более мелких вариантов использования, каждый из которых будет определять сервис элемента модели, содержащийся в сервисе исходной системы. Вариант использования в целом может рассматриваться как суперсервис для уточняющих его подвариантов, которые, в свою очередь, могут рассматриваться как подсервисы исходного варианта использования.

Функциональность, определенная для более общего варианта использования, полностью наследуется всеми вариантами нижних уровней. Однако следует заметить, что структура элемента-контейнера не может быть представлена вариантами использования, поскольку они могут представлять только функциональность отдельных элементов модели. Подчиненные варианты использования кооперируются для совместного выполнения суперсервиса варианта использования верхнего уровня. Эта кооперация также может быть представлена на диаграмме кооперации в виде совместных действий отдельных элементов модели.

Отдельные варианты использования нижнего уровня могут участвовать в нескольких кооперациях, т. е. играть определенную роль при выполнении сервисов нескольких вариантов верхнего уровня. Для отдельных таких коопераций могут быть определены соответствующие роли актеров, взаимодействующих с конкретными вариантами использования нижнего уровня. Эти роли будут играть актеры нижнего уровня модели системы. Хотя некоторые из таких актеров могут быть актерами верхнего уровня, это не противоречит принятым в языке UML семантическим правилам построения диаграмм вариантов использования. Более того, интерфейсы вариантов использования верхнего уровня могут полностью совпадать по своей структуре с соответствующими интерфейсами вариантов нижнего уровня.

Окружение вариантов использования нижнего уровня является самостоятельным элементом модели, который в свою очередь содержит другие элементы модели, определенные для этих вариантов использования. Таким образом, с точки зрения общего представления верхнего уровня взаимодействие между вариантами использования нижнего уровня определяет результат выполнения сервиса варианта верхнего уровня. Отсюда следует, что в языке UML вариант использования является элементом-контейнером.

Варианты использования классов соответствуют операциям этого класса, поскольку сервис класса является по существу выполнением операций данного класса. Некоторые варианты использования могут соответствовать применению только одной операции, в то время как другие — конечного множества операций, определенных в виде последовательности операций. В то же время одна операция может быть необходима для выполнения нескольких сервисов класса и поэтому будет появляться в нескольких вариантах использования этого класса.

Реализация варианта использования зависит от типа элемента модели, в котором он определен. Например, поскольку варианты использования класса определяются посредством операций этого класса, они реализуются соответствующими методами. С другой стороны, варианты использования подсистемы реализуются элементами, из которых состоит данная подсистема. Поскольку подсистема не имеет своего собственного поведения, все предлагаемые подсистемой сервисы должны представлять собой композицию сервисов, предлагаемых отдельными элементами этой подсистемы, т. е., в конечном итоге, классами. Эти элементы могут взаимодействовать друг с другом для совместного обеспечения требуемого поведения отдельного варианта использования. Такое совместное обеспечение требуемого поведения описывается специальным элементом языка UML — кооперация или сотрудничество, который будет рассмотрен в главе 9, посвященной построению диаграмм кооперации. Здесь лишь отметим, что кооперации используются как для уточнения спецификаций в виде вариантов использования нижних уровней диаграммы, так и для описания особенностей их последующей реализации.

Если в качестве моделируемой сущности выступает система или подсистема самого верхнего уровня, то отдельные пользователи вариантов использования этой системы моделируются актерами. Такие актеры, являясь внутренними по отношению к моделируемым подсистемам нижних уровней, часто в явном виде не указываются, хотя и присутствуют неявно в модели подсистемы. Вместо этого варианты использования непосредственно обращаются к тем модельным элементам, которые содержат в себе подобные неявные актеры, т. е. экземпляры которых играют роли таких актеров при взаимодействии с вариантами использования. Эти модельные элементы могут содержаться в других пакетах или подсистемах. В последнем случае роли определяются в том пакете, к которому относится соответствующая подсистема.

С системно-аналитической точки зрения построение диаграммы вариантов использования специфицирует не только функциональные требования к проектируемой системе, но и выполняет исходную структуризацию предметной области. Последняя задача сочетает в себе не только следование техническим рекомендациям, но и является в некотором роде искусством, умением выделять главное в модели системы. Хотя рациональный унифицированный процесс не исключает итеративный возврат в последующем к диаграмме вариантов использования для ее модификации, не вызывает сомнений тот факт, что любая подобная модификация потребует, как по цепочке, изменений во всех других представлениях системы. Поэтому всегда необходимо стремиться к возможно более точному представлению модели именно в форме диаграммы вариантов использования.

Если же варианты использования применяются для спецификации части системы, то они будут эквивалентны соответствующим вариантам использования в модели подсистемы для части соответствующего пакета. Важно понимать, что все сервисы системы должны быть явно определены на диаграмме вариантов использования, и никаких других сервисов, которые отсутствуют на данной диаграмме, проектируемая система не может выполнять по определению. Более того, если для моделирования реализации системы используются сразу несколько моделей (например, модель анализа и модель проектирования), то множество вариантов использования всех пакетов системы должно быть эквивалентно множеству вариантов использования модели в целом.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 5
Диаграмма классов (class diagram)

  • 5.1. Класс
    • Имя класса
    • Атрибуты класса
    • Операция
  • 5.2. Отношения между классами
    • Отношение зависимости
    • Отношение ассоциации
    • Отношение агрегации
    • Отношение композиции
    • Отношение обобщения
  • 5.3. Интерфейсы
  • 5.4. Объекты
  • 5.5. Шаблоны или параметризованные классы
  • 5.6. Рекомендации по построению диаграмм классов

Центральное место в ООАП занимает разработка логической модели системы в виде диаграммы классов. Нотация классов в языке UML проста и интуитивно понятна всем, кто когда-либо имел опыт работы с CASE-инструментариями. Схожая нотация применяется и для объектов — экземпляров класса, с тем различием, что к имени класса добавляется имя объекта и вся надпись подчеркивается.

Нотация UML предоставляет широкие возможности для отображения дополнительной информации (абстрактные операции и классы, стереотипы, общие и частные методы, детализированные интерфейсы, параметризованные классы). При этом возможно использование графических изображений для ассоциаций и их специфических свойств, таких как отношение агрегации, когда составными частями класса могут выступать другие классы.

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы.

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято считать графическим представленном таких структурных взаимосвязей логической модели системы, которые не зависят или инвариантны от времени.

Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области. Эти знания интерпретируются в базовых понятиях языка UML, таких как классы, интерфейсы и отношения между ними и их составляющими компонентами. При этом отдельные компоненты этой диаграммы могут образовывать пакеты для представления более общей модели системы. Если диаграмма классов является частью некоторого пакета, то ее компоненты должны соответствовать элементам этого пакета, включая возможные ссылки на элементы из других пакетов.

В общем случае пакет статической структурной модели может быть представлен в виде одной или нескольких диаграмм классов. Декомпозиция некоторого представления на отдельные диаграммы выполняется с целью удобства и графической визуализации структурных взаимосвязей предметной области. При этом компоненты диаграммы соответствуют элементам статической семантической модели. Модель системы, в свою очередь, должна быть согласована с внутренней структурой классов, которая описывается на языке UML.

5.1. Класс

Класс (class) в языке UML служит для обозначения множества объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами из других классов. Графически класс изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5.1). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы).

Рис. 5.1. Графическое изображение класса на диаграмме классов

Обязательным элементов обозначения класса является его имя. На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником с указанием только имени соответствующего класса (рис. 5.1, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис. 5.1, б) и операциями (рис. 5.1, в).

Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание классов, которые состоят из трех разделов или секций. Иногда в обозначениях классов используется дополнительный четвертый раздел, в котором приводится семантическая информация справочного характера или явно указываются исключительные ситуации.

Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется горизонтальной линией, чтобы сразу отличить класс от других элементов языка UML. Примеры графического изображения классов на диаграмме классов приведены на рис. 5.2. В первом случае для класса "Прямоугольник" (рис. 5.2, а) указаны только его атрибуты — точки на координатной плоскости, которые определяют его расположение. Для класса "Окно" (рис. 5.2, б) указаны только его операции, секция атрибутов оставлена пустой. Для класса "Счет" (рис. 5.2, в) дополнительно изображена четвертая секция, в которой указано исключение — отказ от обработки просроченной кредитной карточки.

Рис.5.2. Примеры графического изображения классов на диаграмме

Имя класса

Имя класса должно быть уникальным в пределах пакета, который описывается некоторой совокупностью диаграмм классов (возможно, одной диаграммой). Оно указывается в первой верхней секции прямоугольника. В дополнение к общему правилу наименования элементов языка UML, имя класса записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что именно имена классов образуют словарь предметной области при ООАП.

В первой секции обозначения класса могут находиться ссылки на стандартные шаблоны или абстрактные классы, от которых образован данный класс и, соответственно, от которых он наследует свойства и методы. В этой секции может приводиться информация о разработчике данного класса и статус состояния разработки, а также могут записываться и другие общие свойства этого класса, имеющие отношение к другим классам диаграммы или стандартным элементам языка UML.

Примерами имен классов могут быть такие существительные, как "Сотрудник", "Компания", "Руководитель", "Клиент", "Продавец", "Менеджер", "Офис" и многие другие, имеющие непосредственное отношение к моделируемой предметной области и функциональному назначению проектируемой системы.

Класс может не иметь экземпляров или объектов. В этом случае он называется абстрактным классом, а для обозначения его имени используется наклонный шрифт (курсив). В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом. Данное обстоятельство является семантическим аспектом описания соответствующих элементов языка UML.

Примечание

В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс. Для этой цели используется специальный символ разделитель — двойное двоеточие "::". Синтаксис строки имени класса в этом случае будет следующий <Имя_пакета>::<Имя_класса>. Другими словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести. Например, если определен пакет с именем "Банк", то класс "Счет" в этом банке может быть записан в виде: "Банк::Счет".

Атрибуты класса

Во второй сверху секции прямоугольника класса записываются его атрибуты (attributes) или свойства. В языке UML принята определенная стандартизация записи атрибутов класса, которая подчиняется некоторым синтаксическим правилам. Каждому атрибуту класса соответствует отдельная строка текста, которая состоит из квантора видимости атрибута, имени атрибута, его кратности, типа значений атрибута и, возможно, его исходного значения:

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и, соответственно, отображается при помощи специальных символов:

  • Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут с этой областью видимости доступен или виден из любого другого класса пакета, в котором определена диаграмма.
  • Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с этой областью видимости недоступен или невиден для всех классов, за исключением подклассов данного класса.
  • И, наконец, знак "-" обозначает атрибут с областью видимости типа закрытый (private). Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

Квантор видимости может быть опущен. В этом случае его отсутствие просто означает, что видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений в традиционных языках программирования, когда отсутствие квантора видимости трактуется как public или private. Однако вместо условных графических обозначений можно записывать соответствующее ключевое слово: public, protected, private.

Примечание

Поскольку язык UML инвариантен относительно реализации своих конструкций в конкретных языках программирования, семантика отдельных кванторов видимости не является строго фиксированной. Значения этих кванторов должны дополнительно уточняться пояснительным текстом на естественном языке или соглашением по использованию соответствующих программно-зависимых синтаксических конструкций.

Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения атрибута.

Кратность атрибута характеризует общее количество конкретных атрибутов данного типа, входящих в состав отдельного класса. В общем случае кратность записывается в форме строки текста в квадратных скобках после имени соответствующего атрибута:

[нижняя_граница1 .. верхняя_граница1, нижняя_граница2.. верхняя_грашца2, ..., нuжняя_гpaнuцak .. верхняя_границаk],

где нижняя_граница и верхняя_граница являются положительными целыми числами, каждая пара которых служит для обозначения отдельного замкнутого интервала целых чисел, у которого нижняя (верхняя) граница равна значению нижняя_граница (верхняя_граница). В целом данное условное обозначение кратности соответствует теоретико-множественному объединению соответствующих интервалов. В качестве верхней_границы может использоваться специальный символ "*", который означает произвольное положительное целое число. Другими словами, это означает неограниченное сверху значение кратности соответствующего атрибута.

Значения кратности из интервала следуют в монотонно возрастающем порядке без пропуска отдельных чисел, лежащих между нижней и верхней границами. При этом придерживаются следующего правила: соответствующие нижние и верхние границы интервалов включаются в значение кратности. Если в качестве кратности указывается единственное число, то кратность атрибута принимается равной данному числу. Если же указывается единственный знак "*", то это означает, что кратность атрибута может быть произвольным положительным целым числом или нулем.

В качестве примера рассмотрим следующие варианты задания кратности атрибутов.

  • [0..1] означает, что кратность атрибута может принимать значение О или 1. При этом 0 означает отсутствие значения для данного атрибута.
  • [0..*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное 0. Эта кратность может быть записана короче в виде простого символа — [*].
  • [1.:*] означает, что кратность атрибута может принимать любое положительное целое значение большее или равное 1.
  • [1..5] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 4, 5.
  • [1..3,5,7] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 5, 7.
  • [1..3,7.. 10] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 7, 8, 9, 10.
  • [1..3,7..*] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, а также любое положительное целое значение большее или равное 7.

Если кратность атрибута не указана, то по умолчанию принимается ее значение равное 1..1, т. е. в точности 1.

Тип атрибута представляет собой выражение, семантика которого определяется языком спецификации соответствующей модели. В нотации UML тип атрибута иногда определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. В простейшем случае тип атрибута указывается строкой текста, имеющей осмысленное значение в пределах пакета или модели, к которым относится рассматриваемый класс.

Можно привести следующие примеры задания имен и типов атрибутов классов:

  • цвет: Соlоr — здесь цвет является именем атрибута, Color — именем типа данного атрибута. Указанная запись может определять традиционно используемую RGB-модель (красный, зеленый, синий) для представления цвета. В этом случае имя типа Color как раз и характеризует семантическую конструкцию, которая применяется в большинстве языков программирования для представления цвета.
  • имя_сотрудника [1..2] : String — здесь имя_сотрудника является именем атрибута, который служит для представления информации об имени, а возможно, и отчестве конкретного сотрудника. Тип атрибута String (Строка) как раз и указывает на тот факт, что отдельное значение имени представляет собой строку текста из одного или двух слов (например, "Кирилл" или "Дмитрий Иванович"). Поскольку во многих языках программирования существует тип данных String, использование соответствующего англоязычного термина не вызывает недоразумения у большинства программистов. Однако, хотя в языке UML все термины даются в англоязычном представлении, использование в качестве типа атрибута Строка в данной ситуации не исключается и определяется только соображениями удобства.
  • видимость:Boolean — здесь видимость есть имя абстрактного атрибута (курсив здесь не случаен), который может характеризовать наличие визуального представления соответствующего класса на экране монитора. В этом случае тип Boolean означает, что возможными значениями данного атрибута является одно из двух логических значений: истина (true) или ложь (false). При этом значение истина может соответствовать наличию графического изображения на экране монитора, а значение ложь — его отсутствию, о чем дополнительно указывается в пояснительном тексте. Поскольку кратность атрибута видимость не указана, она принимает значение 1 по умолчанию. В этой ситуации англоязычное имя типа атрибута вполне оправдано наличием соответствующего базового типа в языках программирования. Абстрактный характер данного атрибута обозначается курсивным текстом в записи данного атрибута.
  • форма:Многоугольник — здесь имя атрибута форма может характеризовать такой класс, который является геометрической фигурой на плоскости. В этом случае тип атрибута Многоугольник указывает на тот факт, что отдельная геометрическая фигура может иметь форму треугольника, прямоугольника, ромба, пятиугольника и любого другого многоугольника, но не окружности или эллипса. Вполне очевидно, что в данной ситуации использование соответствующего англоязычного термина вряд ли целесообразно, поскольку тип Многоугольник не является базовым для языков программирования.

Исходное значение служит для задания некоторого начального значения для соответствующего атрибута в момент создания отдельного экземпляра класса. Здесь необходимо придерживаться правила принадлежности значения типу конкретного атрибута. Если исходное значение не указано, то значение соответствующего атрибута не определено на момент создания нового экземпляра класса. С другой стороны, конструктор соответствующего объекта может переопределять исходное значение в процессе выполнения программы, если в этом возникает необходимость.

В качестве примеров исходных значений атрибутов можно привести следующие дополненные выше варианты задания атрибутов:

  • цвет:Соlоr = (255, 0, 0) — в RGB-модели цвета это соответствует чистому красному цвету в качестве исходного значения для данного атрибута.
  • имя_сотрудника[1..2]:String = Иван Иванович — возможно, это нетипичный случай, который, скорее, соответствует ситуации имя_руководителя[2]:81пп§ = Иван Иванович.
  • видимость:Вооlеаn = истина — может соответствовать ситуации, когда в момент создания экземпляра класса создается видимое на экране монитора окно, соответствующее данному объекту.
  • форма:Многоугольник = прямоугольник — вряд ли требует комментариев, поскольку здесь речь идет о геометрической форме создаваемого объекта.

При задании атрибутов могут быть использованы две дополнительные синтаксические конструкции — это подчеркивание строки атрибута и пояснительный текст в фигурных скобках.

Подчеркивание строки атрибута означает, что соответствующий атрибут может принимать подмножество значений из некоторой области значений атрибута, определяемой его типом. Эти значения можно рассматривать как набор однотипных записей или массив, которые в совокупности характеризуют каждый объект класса.

Например, если некоторый атрибут задан в виде форма: Прямоугольник. то это будет означать, что все объекты данного класса могут иметь несколько различных форм, каждая из которых является прямоугольником. Другим примером может служить задание атрибута в виде номер_счета:Integer. что может означать для объекта Сотрудник наличие некоторого подмножества счетов, общее количество которых заранее не фиксируется.

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в программе при работе с данным типом объектов. Фигурные скобки как раз и обозначают фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем. Отсутствие строки-свойства по умолчанию трактуется так, что значение соответствующего атрибута может быть изменено в программе. Например, строка-свойство в записи атрибута заработная_плата:Currency = = {$500} может служить для обозначения фиксированной заработной платы для каждого объекта класса "Сотрудник" определенной должности в некоторой организации. С другой стороны, запись данного атрибута в виде зара-ботная_плата: Currency = $500 означает уже нечто иное, а именно — при создании нового экземпляра Сотрудник (аналогия — прием на работу нового сотрудника) для него устанавливается по умолчанию заработная плата в $500. Однако для отдельных сотрудников могут быть сделаны исключения как в большую, так и в меньшую сторону, о чем необходимо позаботиться дополнительно в программе.

Операция

В третьей сверху секции прямоугольника записываются операции или методы класса. Операция (operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию. Совокупность операций характеризует функциональный аспект поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная строка, которая состоит из квантора видимости операции, имени операции, выражения типа возвращаемого операцией значения и, возможно, строка-свойство данной операции:

<квантор видимости><имя операции>(список параметров):

<выражение типа возвращаемого значения>{строка-свойство}

Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных значений и, соответственно, отображается при помощи специального символа. Символ "+" обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает операцию с областью видимости типа защищенный (protected). И, наконец, символ "-" используется для обозначения операции с областью видимости типа закрытый (private).

Квантор видимости для операции может быть опущен. В этом случае его отсутствие просто означает, что видимость операции не указывается. Вместо условных графических обозначений также можно записывать соответствующее ключевое слово: public, protected, private.

Примечание

Применительно к конкретным языкам программирования могут быть определены дополнительные кванторы видимости. В этом случае подобные дополнения являются расширением базовой нотации и требуют соответствующих пояснений в форме текста на естественном языке или в виде строки-свойства.

Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса. Имя атрибута является единственным обязательным элементом синтаксического обозначения операции.

Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых может быть представлен в следующем виде:

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

Здесь вид параметра — есть одно из ключевых слов in, out или inout со значением in по умолчанию, в случае если вид параметра не указывается. Имя параметра есть идентификатор соответствующего формального параметра. Выражение типа является зависимой от конкретного языка программирования спецификацией типа возвращаемого значения для соответствующего формального параметра. Наконец, значение по умолчанию в общем случае представляет собой выражение для значения формального параметра, синтаксис которого зависит от конкретного языка программирования и подчиняется принятым в нем ограничениям.

Выражение типа возвращаемого значения также является зависимой от языка реализации спецификацией типа или типов значений параметров, которые возвращаются объектом после выполнения соответствующей операции. Двоеточие и выражение типа возвращаемого значения могут быть опущены, если операция не возвращает никакого значения. Для указания кратности возвращаемого значения данная спецификация может быть записана в виде списка отдельных выражений.

Строка-свойство служит для указания значений свойств, которые могут быть применены к данному элементу. Строка-свойство не является обязательной, она может отсутствовать, если никакие свойства не специфицированы.

Операция с областью действия на весь класс показывается подчеркиванием имени и строки выражения типа. По умолчанию под областью операции понимается объект класса. В этом случае имя и строка выражения типа операции не подчеркиваются.

Операция, которая не может изменять состояние системы и, соответственно, не имеет никакого побочного эффекта, обозначается строкой-свойством "{запрос}" ("{query}"). В противном случае операция может изменять состояние системы, хотя нет никаких гарантий, что она будет это делать.

Для повышения производительности системы одни операции могут выполняться параллельно или одновременно, а другие — только последовательно. В этом случае для указания параллельности выполнения операции используется строка-свойство вида "{concurrency = имя}", где имя может принимать одно из следующих значений: последовательная (sequential), параллельная (concurrent), охраняемая (guarded). При этом придерживаются следующей семантики для данных значений:

  • последовательная (sequential) — для данной операции необходимо обеспечить ее единственное выполнение в системе, одновременное выполнение других операций может привести к ошибкам или нарушениям целостности объектов класса.
  • параллельная (concurrent) — данная операция в силу своих особенностей может выполняться параллельно с другими операциями в системе, при этом параллельность должна поддерживаться на уровне реализации модели.
  • охраняемая (guarded) — все обращения к данной операции должны быть строго упорядочены во времени с целью сохранения целостности объектов данного класса, при этом могут быть приняты дополнительные меры по контролю исключительных ситуаций на этапе ее выполнения.

С целью сокращения обозначений допускается использование одного имени в качестве строки-свойства для указания соответствующего значения параллельности. Отсутствие данной строки-свойства означает, что семантика параллельности для операции не определена. Поэтому следует предположить худший с точки зрения производительности случай, когда данная операция требует последовательного выполнения.

Появление сигнатуры операции на самом верхнем уровне объявляет эту операцию на весь класс, при этом данная операция наследуется всеми потомками данного класса. Если в некотором классе операция не выполняется (т. е. некоторый метод не применяется), то такая операция может быть помечена как абстрактная "{abstract}". Другой способ показать абстрактный характер операции — записать ее сигнатуру курсивом. Подчиненное появление записи данной операции без свойства {абстрактная} указывает на тот факт, что соответствующий класс-потомок может выполнять данную операцию в качестве своего "метода.

Если для некоторой операции необходимо дополнительно указать особенности ее реализации (например, алгоритм), то это может быть сделано в форме примечания, записанного в виде текста, который присоединяется к записи операции в соответствующей секции класса. Если объекты класса принимают и реагируют на некоторый сигнал, то запись данной операции помечается ключевым словом "сигнал" ("signal"). Это обозначение равнозначно обозначению некоторой операции. Реакция объекта на прием сигнала может быть показана в виде некоторого автомата. Кроме других случаев эта нотация может быть использована, чтобы показать реакцию объектов класса на ошибочные ситуации или исключения, которые могут моделироваться как сигналы или сообщения.

Поведение операции может быть указано дополнительно в форме присоединенного к операции примечания. В этом случае текст примечания заключается в скобки, если он представляет собой формальную спецификацию на некотором языке программирования и соответствует элементу "семантическое ограничение языка UML". В противном случае текст примечания является простым описанием на естественном языке и обозначается прямоугольником с "загнутым" верхним правым уголком (см. главу 4).

Список формальных параметров и тип возвращаемого значения могут не указываться. Квантор видимости атрибутов и операций может быть указан в виде специального значка или символа, которые используются для графического представления моделей в некотором инструментальном средстве. Имена операций, так же как и атрибутов, записываются со строчной (малой) буквы, а их типы — с заглавной (большой) буквы. При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок.

В качестве примеров записи операций можно привести следующие обозначения отдельных операций:

  • +создать() — может обозначать абстрактную операцию по созданию отдельного объекта класса, которая является общедоступной и не содержит формальных параметров. Эта операция не возвращает никакого значения после своего выполнения.
  • +нарисовать(форма: Многоугольник = прямоугольник, цвет_заливки: Color = (О, О, 255)) — может обозначать операцию по изображению на экране монитора прямоугольной области синего цвета, если не указываются другие значения в качестве аргументов данной операции.
  • запросить_счет_клиента(номер_счета:1п1е§ег):Сиггепсу — обозначает операцию по установлению наличия средств на текущем счете клиента банка. При этом аргументом данной операции является номер счета клиента, который записывается в виде целого числа (например, "123456"). Результатом выполнения этой операции является некоторое число, записанное в принятом денежном формате (например, $1,500.00).
  • выдать_сообщение():{"Ошибка деления на ноль"} — смысл данной операции не требует пояснения, поскольку содержится в строке-свойстве операции. Данное сообщение может появиться на экране монитора в случае попытки деления некоторого числа на ноль, что недопустимо.

5.2. Отношения между классами

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов отношений. Базовыми отношениями или связями в языке UML являются:

  • Отношение зависимости (dependency relationship)
  • Отношение ассоциации (association relationship)
  • Отношение обобщения (generalization relationship)
  • Отношение реализации (realization relationship)

Каждое из этих отношений имеет собственное графическое представление на диаграмме, которое отражает взаимосвязи между объектами соответствующих классов.

Отношение зависимости

Отношение зависимости в общем случае указывает некоторое семантическое отношение между двумя элементами модели или двумя множествами таких элементов, которое не является отношением ассоциации, обобщения или реализации. Оно касается только самих элементов модели и не требует множества отдельных примеров для пояснения своего смысла. Отношение зависимости используется в такой ситуации, когда некоторое изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели.

Отношение зависимости графически изображается пунктирной линией между соответствующими элементами со стрелкой на одном из ее концов ("—>" или "<—"). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рис. 5.3). На данном рисунке изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А — клиентом этой зависимости.

Рис. 5.3. Графическое изображение отношения зависимости на диаграмме классов

В качестве класса-клиента и класса-источника зависимости могут выступать целые множества элементов модели. В этом случае одна линия со стрелкой, выходящая от источника зависимости, расщепляется в некоторой точке на несколько отдельных линий, каждая из которых имеет отдельную стрелку для класса-клиента. Например, если функционирование Класса_С зависит от особенностей реализации Класса_А и Класса_/>, то данная зависимость может быть изображена следующим образом (рис. 5.4).

Рис. 5.4. Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_Л и Класс_Б)

Стрелка может помечаться необязательным, но стандартным ключевым словом в кавычках и необязательным индивидуальным именем. Для отношения зависимости предопределены ключевые слова, которые обозначают некоторые специальные виды зависимостей. Эти ключевые слова (стереотипы) записываются в кавычках рядом со стрелкой, которая соответствует данной зависимости. Примеры стереотипов для отношения зависимости представлены ниже:

  • "access" — служит для обозначения доступности открытых атрибутов и операций класса-источника для классов-клиентов;
  • "bind" — класс-клиент может использовать некоторый шаблон для своей последующей параметризации;
  • "derive" — атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
  • "import" — открытые атрибуты и операции класса-источника становятся частью класса-клиента, как если бы они были объявлены непосредственно в нем;
  • "refine" — указывает, что класс-клиент служит уточнением класса-источника в силу причин исторического характера, когда появляется дополнительная информация в ходе работы над проектом.

Примечание

Отношение зависимости является наиболее общей формой отношения в языке UML. Все другие типы рассматриваемых отношений можно считать частным случаем данного отношения. Однако важность выделения специфических семантических свойств и дополнительных характеристик для других типов отношений обусловливают их самостоятельное рассмотрение при построении диаграмм.

Отношение ассоциации

Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное отношение обозначается сплошной линией с дополнительными специальными символами, которые характеризуют отдельные свойства конкретной ассоциации. В качестве дополнительных специальных символов могут использоваться имя ассоциации, а также имена и кратность классов-ролей ассоциации. Имя ассоциации является необязательным элементом ее обозначения. Если оно задано, то записывается с заглавной (большой) буквы рядом с линией соответствующей ассоциации.

Наиболее простой случай данного отношения — бинарная ассоциация. Она связывает в точности два класса и, как исключение, может связывать класс с самим собой. Для бинарной ассоциации на диаграмме может быть указан порядок следования классов с использованием треугольника в форме стрелки рядом с именем данной ассоциации. Направление этой стрелки указывает на порядок классов, один из которых является первым (со стороны треугольника), а другой — вторым (со стороны вершины треугольника). Отсутствие данной стрелки рядом с именем ассоциации означает, что порядок следования классов в рассматриваемом отношении не определен.

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между двумя классами — классом "Компания" и классом "Сотрудник" (рис. 5.5). Они связаны между собой бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для данного отношения определен порядок следования классов, первым из которых является класс "Сотрудник", а вторым — класс "Компания". Отдельным примером или экземпляром данного отношения может являться пара значений (Петров И. И., "Рога&Копыта"). Это означает, что сотрудник Петров И. И. работает в компании "Рога&Копыта".

Рис. 5.5. Графическое изображение отношения бинарной ассоциации между классами

Тернарная ассоциация и ассоциации более высокой арности в общем случае называются N-арной ассоциацией (читается — "эн арная ассоциация"). Такая ассоциация связывает некоторым отношением 3 и более классов, при этом один класс может участвовать в ассоциации более чем один раз. Класс ассоциации имеет определенную роль в соответствующем отношении, что может быть явно указано на диаграмме. Каждый экземпляр N-арной ассоциации представляет собой N-арный кортеж значений объектов из соответствующих классов. Бинарная ассоциация является частным случаем N-арной ассоциации, когда значение N=2, и имеет свое собственное обозначение.

N-арная ассоциация графически обозначается ромбом, от которого ведут линии к символам классов данной ассоциации. В этом случае ромб соединяется с символами соответствующих классов сплошными линиями. Обычно линии проводятся от вершин ромба или от середины его сторон. Имя N-арной ассоциации записывается рядом с ромбом соответствующей ассоциации.

Порядок классов в N-арной ассоциации, в отличие от порядка множеств в отношении, на диаграмме не фиксируется. Некоторый класс может быть присоединен к ромбу пунктирной линией. Это означает, что данный класс обеспечивает поддержку свойств соответствующей N-арной ассоциации, а сама N-арная ассоциация имеет атрибуты, операции и/или ассоциации. Другими словами, такая ассоциация, в свою очередь, является классом с соответствующим обозначением в виде прямоугольника и является самостоятельным элементом языка UML — ассоциацией-классом (Association Class). N-арная ассоциация не может содержать символ агрегации ни для какой из своих ролей.

В качестве примера конкретной тернарной ассоциации рассмотрим отношение между тремя классами: "Футбольная команда", "Год" и "Игра". Данная ассоциация указывает на наличие отношения между этими тремя классами, которое может представлять информацию об играх футбольных команд в национальном чемпионате в течение нескольких последних лет (рис. 5.6).

Как уже упоминалось, отдельный класс ассоциации имеет собственную роль в отношении. Эта роль может быть изображена графически на диаграмме классов. С этой целью в языке UML вводится в рассмотрение специальный элемент — конец ассоциации (Association End), который графически соответствует точке соединения линии ассоциации с отдельным классом. Конец ассоциации является частью ассоциации, но не класса. Каждая ассоциация имеет два или больше концов ассоциации. Наиболее важные свойства ассоциации указываются на диаграмме рядом с этими элементами ассоциации и должны перемешаться вместе с ними.

Рис. 5.6. Графическое изображение тернарной ассоциации между тремя классами

Одним из таких дополнительных обозначений является имя роли отдельного класса, входящего в ассоциацию. Имя роли представляет собой строку текста рядом с концом ассоциации для соответствующего класса. Она указывает специфическую роль, которую играет класс, являющийся концом рассматриваемой ассоциации. Имя роли не является обязательным элементом обозначений и может отсутствовать на диаграмме.

Следующий элемент обозначений — кратность отдельных классов, являющихся концами ассоциации. Кратность отдельного класса обозначается в виде интервала целых чисел, аналогично кратности атрибутов и операций классов. Интервал записывается рядом с концом ассоциации и для N-арной ассоциации означает потенциальное число отдельных экземпляров или значений кортежей этой ассоциации, которые могут иметь место, когда остальные N-1 экземпляров или значений классов фиксированы.

Так, для рассмотренного ранее примера (см. рис. 5.5) кратность "1" для класса "Компания" означает, что каждый сотрудник может работать только в одной компании. Кратность "1..*" для класса "Сотрудник" означает, что в каждой компании могут работать несколько сотрудников, общее число которых заранее неизвестно и ничем не ограничено. Заметим, что вместо кратности "1..*" записать только символ "*" нельзя, поскольку последний означает кратность "0..*". Для данного примера это означало бы, что отдельные компании могут совсем не иметь сотрудников в своем штате. Но такая кратность вполне приемлема в других ситуациях, как это видно из рассмотренного выше примера (рис. 5.6).

Что касается других свойств отношения, ассоциации, то в случае их наличия, они могут рассматриваться в качестве атрибутов класса ассоциации и могут быть указаны на диаграмме обычным для класса способом в соответствующей секции прямоугольника класса.

Частным случаем отношения ассоциации является так называемая исключающая ассоциация (Xor-association). Семантика данной ассоциации указывает на тот факт, что из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. На диаграмме классов исключающая ассоциация изображается пунктирной линией, соединяющей две и более ассоциации, рядом с которой записывается строка-ограничение "{хог}".

Например, счет в банке может быть открыт для клиента, в качестве которого может выступать физическое лицо (индивидум) или компания, что изображается с помощью исключающей ассоциации (рис. 5.7).

Рис. 5.7. Графическое изображение исключающей ассоциации между тремя классами

Специальной формой или частным случаем отношения ассоциации является отношение агрегации, которое, в свою очередь, тоже имеет специальную форму — отношение композиции. Поскольку эти отношения имеют свои специальные обозначения и относятся к базовым понятиям языка UML, рассмотрим их последовательно.

Отношение агрегации

Отношение агрегации имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности.

Данное отношение имеет фундаментальное значение для описания структуры сложных систем, поскольку применяется для представления системных взаимосвязей типа "часть-целое". Раскрывая внутреннюю структуру системы, отношение агрегации показывает, из каких компонентов состоит система и как они связаны между собой. С точки зрения модели отдельные части системы могут выступать как в виде элементов, так и в виде подсистем, которые, в свою очередь, тоже могут образовывать составные компоненты или подсистемы. Это отношение по своей сути описывает декомпозицию или разбиение сложной системы на более простые составные части, которые также могут быть подвергнуты декомпозиции, если в этом возникнет необходимость в последующем.

Примечание

В связи с рассмотрением данного отношения вполне уместно вспомнить о специальном термине "агрегат", которое служит для обозначения технической системы, состоящей из взаимодействующих составных частей или подсистем. Эта аналогия не случайна и может служить для более наглядного понимания сути рассматриваемого отношения.

Очевидно, что рассматриваемое в таком аспекте деление системы на составные части представляет собой некоторую иерархию ее компонентов, однако данная иерархия принципиально отличается от иерархии, порождаемой отношением обобщения. Отличие заключается в том, что части системы никак не обязаны наследовать ее свойства и поведение, поскольку являются вполне самостоятельными сущностями. Более того, части целого обладают своими собственными атрибутами и операциями, которые существенно отличаются от атрибутов и операций целого.

В качестве примера отношения агрегации рассмотрим взаимосвязь типа "часть-целое", которая имеет место между сущностью "Грузовой автомобиль" и такими компонентами, как "Двигатель", "Шасси", "Кабина", "Кузов". Не претендуя на точное соответствие терминологии данной предметной области, нетрудно представить себе, что грузовой автомобиль состоит из двигателя, шасси, кабины и кузова. Именно это отношение между классом "Грузовой_автомобиль" и классами "Двигатель", "Шасси", "Кабина", "Кузов" описывает отношение агрегации.

Графически отношение агрегации изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой "целое". Остальные классы являются его "частями" (рис. 5.8).

Рис. 5.8. Графическое изображение отношения агрегации в языке UML

Еще одним примером отношения агрегации может служить известное каждому из читателей деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь. Используя обозначения языка UML, компонентный состав ПК можно представить в виде соответствующей диаграммы классов (рис. 5.9), которая в данном случае иллюстрирует отношение агрегации.

Рис. 5.9. Диаграмма классов для иллюстрации отношения агрегации на примере ПК

Отношение композиции

Отношение композиции, как уже упоминалось ранее, является частным случаем отношения агрегации. Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части.

Возможно, не самый лучший, но наверняка понятный всем пример этого отношения представляет собой живая клетка в биологии. Другой пример — окно интерфейса программы, которое может состоять из строки заголовка, кнопок управления размером, полос прокрутки, главного меню, рабочей области и строки состояния. Нетрудно понять, что подобное окно представляет собой класс, а его компоненты являются как классами, так и атрибутами или свойствами окна. Последнее обстоятельство весьма характерно для отношения композиции, поскольку отражает различные способы представления данного отношения.

Графически отношение композиции изображается сплошной линией, один из концов которой представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который представляет собой класс-композицию или "целое". Остальные классы являются его "частями" (рис. 5.10).

Рис. 5.10. Графическое изображение отношения композиции в языке UML

В качестве дополнительных обозначений для отношений композиции и агрегации могут использоваться дополнительные обозначения, применяемые для отношения ассоциации. А именно, указание кратности класса ассоциации и имени данной ассоциации, которые не являются обязательными. Применительно к описанному выше примеру класса "Окно_программы" его диаграмма классов может иметь следующий вид (рис. 5.11).

Рис. 5.11. Диаграмма классов для иллюстрации отношения композиции на примере класса окна программы

Данный пример может иллюстрировать и другие особенности разрабатываемой компьютерной программы, которые не указывались в явном виде при описании этого примера Так, в частности, указание кратности 1 рядом с классом "Рабочая_область" характерно для однодокументных приложений.

Отношение обобщения

Отношение обобщения является обычным таксономическим отношением между более общим элементом (родителем или предком) и более частным или специальным элементом (дочерним или потомком). Данное отношение может использоваться для представления взаимосвязей между пакетами, классами, вариантами использования и другими элементами языка UML.

Применительно к диаграмме классов данное отношение описывает иерархическое строение классов и наследование их свойств и поведения. При этом предполагается, что класс-потомок обладает всеми свойствами и поведением класса-предка, а также имеет свои собственные свойства и поведение, которые отсутствуют у класса-предка. На диаграммах отношение обобщения обозначается сплошной линией с треугольной стрелкой на одном из концов (рис. 5.12). Стрелка указывает на более общий класс (класс-предок или суперкласс), а ее отсутствие — на более специальный класс (класс-потомок или подкласс).

Рис. 5.12. Графическое изображение отношения обобщения в языке UML

Как правило, на диаграмме может указываться несколько линий для одного отношения обобщения, что отражает его таксономический характер. В этом случае более общий класс разбивается на подклассы одним отношением Обобщения. Например, класс Геометрическая_фигура_на_плоскости (курсив обозначает абстрактный класс) может выступать в качестве суперкласса для подклассов, соответствующих конкретным геометрическим фигурам, таким как,Прямоугольник, Окружность, Эллипс и др. Данный факт может быть представлен графически в форме диаграммы классов следующего вида (рис. 5.13).

Рис. 5.13. Пример графического изображения отношения обобщения классов

С целью упрощения обозначений на диаграмме классов совокупность линий, обозначающих одно и то же отношение обобщения, может быть объединена в одну линию. В этом случае данные отдельные линии изображаются сходящимися к единственной .стрелке, имеющей с ними общую точку пересечения (рис. 5.14).

Рис. 5.14. Вариант графического изображения отношения обобщения классов для случая объединения отдельных линий

Это обозначение по форме соответствует графу специального вида, который рассматривался в главе 2, а именно — иерархическому дереву. В этом случае класс-предок является корнем этого дерева, а классы-потомки — его листьями. Отличие заключается в возможности указания на диаграмме классов потенциальной возможности наличия других классов-потомков, которые не включены в обозначения представленных на диаграмме классов (многоточие вместо прямоугольника).

Рядом со стрелкой обобщения может размещаться строка текста, указывающая на некоторые дополнительные свойства этого отношения. Данный текст будет относиться ко всем линиям обобщения, которые идут к классам-потомкам. Другими словами, отмеченное свойство касается всех подклассов данного отношения. При этом текст следует рассматривать как ограничение, и тогда он записывается в фигурных скобках.

В качестве ограничений могут быть использованы следующие ключевые слова языка UML:

  • {complete} — означает, что в данном отношении обобщения специфицированы все классы-потомки, и других классов-потомков у данного класса-предка быть не может. Пример — класс Клиент_банка является предком для двух классов: Физическое_лицо и Компания, и других классов-потомков он не имеет. На соответствующей диаграмме классов это можно указать явно, записав рядом с линией обобщения данную строку-ограничение;
  • {disjoint} — означает, что классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов. В приведенном выше примере это условие также выполняется, поскольку предполагается, что никакое конкретное физическое лицо не может являться одновременно и конкретной компанией. В этом случае рядом с линией обобщения можно записать данную строку-ограничение;
  • {incomplete} — означает случай, противоположный первому. А именно, предполагается, что на диаграмме указаны не все классы-потомки. В последующем возможно восполнить их перечень не изменяя уже построенную диаграмму. Пример — диаграмма класса "Автомобиль", для которой указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего каталога. С другой стороны, для отдельной задачи, такой как разработка системы продажи автомобилей конкретных моделей, в этом нет необходимости. Но указать неполноту структуры классов-потомков все же следует;
  • {overlapping} — означает, что отдельные экземпляры классов-потомков могут принадлежать одновременно нескольким классам. Пример — класс "Многоугольник" является классом-предком для класса "Прямоугольник" и класса "Ромб". Однако существует отдельный класс "Квадрат", экземпляры которого одновременно являются объектами первых двух классов. Вполне естественно такую ситуацию указать явно с помощью данной строки-ограничения.

С учетом возможности использования строк-ограничений диаграмма классов (рис. 5.14) может быть изображена без многоточий и без потери информации (рис. 5.15).

Рис. 5.15. Вариант графического изображения отношения обобщения классов с использованием строки-ограничения

Чтобы проиллюстрировать особенности использования отношения обобщения, преобразуем один из рассмотренных ранее примеров изображения классов в графическую нотацию языка UML. В качестве такого примера рассмотрим иерархию вложенности классов для абстрактного класса "Автомобиль" (см. рис. 1,2, 2.7). Как нетрудно заметить, отношение между отдельными классами на этих рисунках есть именно отношение обобщения, которое в языке UML имеет специальное графическое обозначение. С учетом этой графической нотации, фрагмент семантической сети для представления иерархии класса "Автомобиль" (см. рис. 2.7) может быть представлен в виде следующей диаграммы классов (рис. 5.16).

Заметим, что в данном примере все классы верхних уровней являются абстрактными, т. е. не могут быть представлены своими экземплярами. Именно поэтому их имена записаны курсивом. В отличие от них классы нижнего уровня являются конкретными, поскольку могут быть представлены своими экземплярами, в качестве которых выступают изготовленные автомобили соответствующей модели с уникальным заводским номером.

Рис. 5.16. Фрагмент диаграммы классов с отношением обобщения для представления иерархии классов "Автомобиль" из рассмотренного ранее примера (см. рис. 2.7)

Примечание

В качестве упражнения для закрепления рассмотренного материала можно попытаться построить диаграммы классов или хотя бы их фрагменты для библиотек стандартных классов MFC (Microsoft) и VCL (Borland/Inprise) с использованием графической нотации языка UML. Можно предположить, что в недалеком будущем справочные руководства по соответствующим средам программирования будут содержать именно такие диаграммы классов, а возможно, и некоторые другие.

5.3. Интерфейсы .

Интерфейсы являются элементами диаграммы вариантов использования и были рассмотрены в главе 4. Однако при построении диаграммы классов отдельные интерфейсы могут уточняться и в этом случае для их изображения используется специальный графический символ — прямоугольник класса с ключевым словом или стереотипом "interface" (рис. 5.17). При этом секция атрибутов у прямоугольника отсутствует, а указывается только секция операций.

Рис. 5.17. Пример графического изображения интерфейса на диаграмме классов

5.4. Объекты

Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он имеет свое собственное имя и конкретные значения атрибутов. В силу самых различных причин может возникнуть необходимость показать взаимосвязи не только между классами модели, но и между отдельными объектами, реализующими эти классы. В данном случае может быть разработана диаграмма объектов, которая, хотя и не является канонической в метамодели языка UML, но имеет самостоятельное назначение.

Для графического изображения объектов используется такой же символ прямоугольника, что и для классов. Отличия проявляются при указании имен объектов, которые в случае объектов обязательно подчеркиваются (рис. 5.18). При этом запись имени объекта представляет собой строку текста "имя объекта:имя класса", разделенную двоеточием (рис. 5.18 а, б). Имя объекта может отсутствовать, в этом случае предполагается, что объект является анонимным, и двоеточие указывает на данное обстоятельство (рис. 5.18, г). Отсутствовать может и имя класса. Тогда указывается просто имя объекта (рис. 5.18, в). Атрибуты объектов принимают конкретные значения.

При изображении диаграммы объектов нужно помнить, что каждый объект представляет собой экземпляр соответствующего класса, а отношения между объектами описываются с помощью связей (links), которые являются экземплярами соответствующих отношений. При этом все связи изображаются сплошными линиями. Более подробно особенности представления объектов будут рассмотрены в главе 9 при изучении диаграмм кооперации.

Рис. 5.18. Пример графического изображения объектов на диаграммах языка UML

5.5. Шаблоны или параметризованные классы

Шаблон (template) или параметризованный класс (parametrized class) предназначен для обозначения такого класса, который имеет один (или более) нефиксированный формальный параметр. Он определяет целое семейство или множество классов, каждый из которых может быть получен связыванием этих параметров с действительными значениями. Обычно параметрами шаблонов служат типы атрибутов классов, такие как целые числа, перечисление, массив строк и др. В более сложном случае формальные параметры могут представлять и операции класса.

Графически шаблон изображается прямоугольником, к верхнему правому углу которого присоединен маленький прямоугольник из пунктирных линий (рис. 5.19), большой прямоугольник может быть разделен на секции, аналогично обозначению для класса. В верхнем прямоугольнике указывается список формальных параметров для тех классов, которые могут быть получены на основе данного шаблона. В верхней секции шаблона записывается его имя по правилам записи имен для классов.

Рис. 5.19. Графическое изображение шаблона на диаграмме классов

Шаблон не может быть непосредственно использован в качестве класса, поскольку содержит неопределенные параметры. Чаще всего в качестве шаблона выступает некоторый суперкласс, параметры которого уточняются в его классах-потомках. Очевидно, в этом случае между ними существует отношение зависимости с ключевым словом "bind", когда класс-клиент может использовать некоторый шаблон для своей последующей параметризации. В более частном случае между шаблоном и формируемым от него классом имеет место отношение обобщения с наследованием свойств шаблона (рис. 5.20). В данном примере отмечен тот факт, что класс "Адрес" может быть получен из шаблона Связный_список на основе актуализации формальных параметров "S, k, l" фактическими атрибутами "улица, дом, квартира".

Этот же шаблон может использоваться для задания (инстанцирования) другого класса, скажем, класса "Точки_на_плоскости". В этом случае класс "Точки_на_плоскости" актуализирует те же формальные параметры, но с другими значениями, например, "ЬтсГ<координаты_точки, х, у>. Концепция шаблонов является достаточно мощным средством в ООП, и поэтому ее использование в языке UML позволяет не только сократить размеры диаграмм, но и наиболее корректно управлять наследованием свойств и поведения отдельных элементов модели.

Рис. 5.20. Пример использования шаблона на диаграмме классов

5.6. Рекомендации по построению диаграмм классов

Процесс разработки диаграммы классов занимает центральное место в ООАП сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность выполнения программы. Как показывает практика ООП, каждый программист в своей работе стремится в той или иной степени использовать уже накопленный личный опыт при разработке новых проектов. Это обусловлено желанием свести новую задачу к уже решенным, чтобы иметь возможность использовать не только проверенные фрагменты программного кода, но и отдельные компоненты в целом (библиотеки компонентов).

Такой стереотипный подход позволяет существенно сократить сроки реализации проекта, однако приемлем лишь в том случае, когда новый проект концептуально и технологически не слишком отличается от предыдущих. В противном случае платой за сокращение сроков проекта может стать его реализация на устаревшей технологической базе. Что касается собственно объектной структуризации предметной области, то здесь уместно придерживаться тех рекомендаций, которые накоплены в ООП. Они широко освещены в литературе [1, 2, 4, 10, 13, 18, 20] и поэтому здесь не рассматриваются.

При определении классов, атрибутов и операций и задании их имен и типов перед отечественными разработчиками всегда встает невольный вопрос: какой из языков использовать в качестве естественного, русский или английский? С одной стороны, использование родного языка для описания модели является наиболее естественным способом ее представления и в наибольшей степени отражает коммуникативную функцию модели системы. С другой стороны, разработка модели является лишь одним из этапов разработки соответствующей системы, а применение инструментальных средств для ее реализации в абсолютном большинстве случаев требует использования англоязычных терминов. Именно поэтому возникает характерная неоднозначность, с которой, по-видимому, совершенно незнакома англоязычная аудитория.

Отвечая на поставленный выше вопрос, следует отметить, что наиболее целесообразно придерживаться следующих рекомендаций. При построении диаграммы вариантов использования, являющейся наиболее общей концептуальной моделью проектируемой системы, применение русскоязычных терминов является не только оправданным с точки зрения описания структуры предметной области, но и эффективным с точки зрения коммуникативного взаимодействия с заказчиком и пользователями. При построении остальных типов диаграмм следует придерживаться разумного компромисса.

В частности, на начальных этапах разработки диаграмм целесообразность использования русскоязычных терминов вполне очевидна и оправдана. Однако, по мере готовности графической модели для реализации в виде программной системы и передачи ее для дальнейшей работы программистам, акцент может смещаться в сторону использования англоязычных терминов, которые в той или иной степени отражают особенности языка программирования, на котором предполагается реализация данной модели.

Более того, использование CASE-инструментариев для автоматизации ООАП, чаще всего, накладывает свои собственные требования на язык спецификации моделей. Именно по этой причине большинство примеров в литературе даются в англоязычном представлении, а при их переводе на русский может быть утрачена не только точность формулировок, но и семантика соответствующих понятий.

После разработки диаграммы классов процесс ООАП может быть продолжен в двух направлениях. С одной стороны, если поведение системы тривиально, то можно приступить к разработке диаграмм кооперации и компонентов. Однако для сложных динамических систем поведение представляет важнейший аспект их функционирования. Детализация поведения осуществляется последовательно при разработке диаграмм состояний, последовательности и деятельности. К изучению первой из них мы и приступим в главе 6.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 6
Диаграмма состояний (statechart diagram)

  • 6.1. Автоматы
  • 6.2. Состояние
    • Имя состояния
    • Список внутренних действий
    • Начальное состояние
    • Конечное состояние
  • 6.3. Переход
    • Событие
    • Сторожевое условие
    • Выражение действия
  • 6.4. Составное состояние и подсостояние
    • Последовательные подсостояния
    • Параллельные подсостояния
  • 6.5. Историческое состояние
  • 6.6. Сложные переходы
    • Переходы между параллельными состояниями
    • Переходы между составными состояниями
    • Синхронизирующие состояния
  • 6.7. Заключительные рекомендации по построению диаграмм состояний

Рассмотренная выше диаграмма классов представляет собой логическую модель статического представления моделируемой системы. Речь идет о том, что на данной диаграмме изображаются только взаимосвязи структурного характера, не зависящие от времени или реакции системы на внешние события. Однако для большинства физических систем, кроме самых простых и тривиальных, статических представлений совершенно недостаточно для моделирования процессов функционирования подобных систем как в целом, так и их отдельных подсистем и элементов.

Рассмотрим простой пример. Любое техническое устройство, такое как телевизор, компьютер, автомобиль, телефонный аппарат в самом общем случае может характеризоваться такими своими состояниями, как "исправен" и "неисправен". Интуитивно ясно, какой смысл вкладывается в каждое из этих понятий. Более того, использование по назначению данного устройства возможно только тогда, когда оно находится в исправном состоянии. В противном случае необходимо предпринять совершенно конкретные действия по его ремонту и восстановлению работоспособности.

Однако понимание семантики понятия состояния представляет определенные трудности. Дело в том, что характеристика состояний системы не зависит (или слабо зависит) от логической структуры, зафиксированной в диаграмме классов. Поэтому при рассмотрении состояний системы приходится на время отвлечься от особенностей ее объектной структуры и мыслить совершенно другими категориями, образующими динамический контекст поведения моделируемой системы. Поэтому при построении диаграмм состояний необходимо использовать специальные понятия, которые и будут рассмотрены в данной главе.

Ранее, в главах 1 и 4, было отмечено, что каждая прикладная система характеризуется не только структурой составляющих ее элементов, но и некоторым поведением или функциональностью. Для общего представления функциональности моделируемой системы предназначены диаграммы вариантов использования, которые на концептуальном уровне описывают поведение системы в целом. Сейчас наша задача заключается в том, чтобы представить поведение более детально на логическом уровне, тем самым раскрыть сущность ответа на вопрос: "В процессе какого поведения система обеспечивает необходимую функциональность?".

Для моделирования поведения на логическом уровне в языке UML могут использоваться сразу несколько канонических диаграмм: состояний, деятельности, последовательности и кооперации, каждая из которых фиксирует внимание на отдельном аспекте функционирования системы. В отличие от других диаграмм диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее — одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний.

Главное предназначение этой диаграммы — описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Системы, которые реагируют на внешние действия от других систем или от пользователей, иногда называют реактивными. Если такие действия инициируются в произвольные случайные моменты времени, то говорят об асинхронном поведении модели.

Хотя диаграммы состояний чаще всего используются для описания поведения отдельных экземпляров классов (объектов), но они также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы.

Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Понятие автомата в контексте UML обладает довольно специфической семантикой, основанной на теории автоматов. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга, образуая вложенные диаграммы более детального представления отдельных элементов модели. Для понимания семантики конкретной диаграммы состояний необходимо представлять не только особенности поведения моделируемой сущности, но и знать общие сведения по теории автоматов.

6.1. Автоматы

Автомат (state machine) в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом. В метамодели UML автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов. С другой стороны, автомат описывает поведение отдельного объекта в форме последовательности состояний, которые охватывают все этапы его жизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Каждая диаграмма состояний представляет некоторый автомат.

Простейшим примером визуального представления состояний и переходов на основе формализма автоматов может служить рассмотренная выше ситуация с исправностью технического устройства, такого как компьютер. В этом случае вводятся в рассмотрение два самых общих состояния: "исправен" и "неисправен" и два перехода: "выход из строя" и "ремонт". Графически эта информация может быть представлена в виде изображенной ниже диаграммы состояний компьютера (рис. 6.1).

Рис. 6.1. Простейший пример диаграммы состояний для технического устройства типа компьютер

Основными понятиями, входящими в формализм автомата, являются состояние и переход. Главное различие между ними заключается в том, что длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода из одного состояния в другое равно нулю (если дополнительно ничего не сказано). Другими словами, переход объекта из состояния в состояние происходит мгновенно.

В общем случае автомат представляет динамические аспекты моделируемой системы в виде ориентированного графа, вершины которого соответствуют состояниям, а дуги — переходам. При этом поведение моделируется как последовательное перемещение по графу состояний от вершины к вершине по связывающим их дугам с учетом их ориентации. Для графа состояний системы можно ввести в рассмотрение специальные свойства.

Одним из таких свойств является выделение из всей совокупности состояний двух специальных: начального и конечного. Хотя ни в графе состояний, ни на диаграмме состояний время нахождения системы в том или ином состоянии явно не учитывается, предполагается, что последовательность изменения состояний упорядочена во времени. Другими словами, каждое последующее состояние всегда наступает позже предшествующего ему состояния.

Еще одним свойством графа состояний может служить достижимость состояний. Речь идет о том, что навигация или ориентированный путь в графе состояний определяет специальное бинарное отношение на множестве всех состояний системы. Это отношение характеризует потенциальную возможность перехода системы из рассматриваемого состояния в некоторое другое состояние. Очевидно, для достижимости состояний необходимо наличие связывающего их ориентированного пути в графе состояний.

Формализм автоматов допускает вложение одних автоматов в другие для уточнения внутренней структуры отдельных более общих состояний (макросостояний). В этом случае вложенные автоматы получили название подавтоматов. Подавтоматы могут использоваться для внутренней спецификации процедур и функций, образующих поведение исходного объекта. Например, состояние неисправности технического устройства (рис. 6.1) может быть детализировано на отдельные подсостояния, каждое из которых может характеризовать неисправность отдельных подсистем, входящих в состав данного устройства.

В языке UML понятие автомата дополнено специальной семантикой входящих в соответствующий пакет элементов. Далее в этой главе будут рассмотрены основные элементы поведения, которые образуют концептуальный базис, необходимый для правильного построения диаграмм состояний.

Формализм обычного автомата основан на выполнении следующих обязательных условий:

  1. Автомат не запоминает историю перемещения из состояния в состояние. С точки зрения моделируемого поведения определяющим является сам факт нахождения объекта в том или ином состоянии, но никак не последовательность состояний, в результате которой объект перешел в текущее состояние. Другими словами, автомат "забывает" все состояния, которые предшествовали текущему в данный момент времени. Образно говоря, существует непрозрачная стена, отделяющая текущее состояние от прошлого поведения объекта.

Примечание

Данное условие может быть изменено явным образом для сохранения некоторых аспектов предыстории поведения объекта на основе введения в рассмотрение так называемых исторических состояний, которые будут описаны ниже в этой главе.

  2. В каждый момент времени автомат может находиться в одном и только в одном из своих состояний. Это означает, что формализм автомата предназначен для моделирования последовательного поведения, когда объект в течение своего жизненного цикла последовательно проходит через все свои состояния. При этом автомат может находиться в отдельном состоянии как угодно долго, если не происходит никаких событий.

Примечание

Это условие ограничивает применение автоматов для моделирования последовательных процессов. Необходимость моделирования параллельных процессов приводит к рассмотрению в контексте одной модели нескольких автоматов, каждый из которых специфицирует отдельный процесс поведения.

  3. Хотя процесс изменения состояний автомата происходит во времени, явно концепция времени не входит в формализм автомата. Это означает, что длительность нахождения автомата в том или ином состоянии, а также время достижения того или иного состояния никак не специфицируются. Другими словами, время на диаграмме состояний присутствует в неявном виде, хотя для отдельных событий может быть указан интервал времени и в явном виде.

Примечание

Концепция времени в явной форме учитывается при построении диаграммы деятельности, когда требуется синхронизировать во времени процессы взаимодействия нескольких объектов модели. Поскольку диаграмма состояний предназначена для моделирования поведения объекта, которое определяется асинхронными событиями, эти события могут происходить в заранее неизвестные моменты времени.

  4. Количество состояний автомата должно быть обязательно конечным (в языке UML рассматриваются только конечные автоматы), и все они должны быть специфицированы явным образом. При этом отдельные псевдосостояния могут не иметь спецификаций (начальное и конечное состояния). В этом случае их назначение и семантика полностью определяются из контекста модели и рассматриваемой диаграммы состояний.
  5. Граф автомата не должен содержать изолированных состояний и переходов. Это условие означает, что для каждого из состояний, кроме начального, должно быть определено предшествующее состояние. Каждый переход должен обязательно соединять два состояния автомата. Допускается переход из состояния в себя, такой переход еще называют "петлей".
  6. Автомат не должен содержать конфликтующих переходов, т. е. таких переходов из одного и того же состояния, когда объект одновременно может перейти в два и более последующих состояния (кроме случая параллельных подавтоматов). В языке UML исключение конфликтов возможно на основе введения так называемых сторожевых условий, которые будут рассмотрены ниже.

Таким образом, правила поведения объекта, моделируемого некоторым автоматом, определяются, с одной стороны, общим формализмом автомата, а с другой — его графическим изображением в языке UML в форме конкретной диаграммы состояний.

6.2. Состояние

Понятие состояния (state) является фундаментальным не только в метамоде-ли языка UML, но и в прикладном системном анализе. Ранее в главе 1 кратко были рассмотрены особенности представления динамических характеристик сложных систем, традиционно используемых для моделирования поведения. Вся концепция динамической системы основывается на понятии состояния системы. Однако семантика состояния в языке UML имеет целый ряд специфических особенностей.

В языке UML под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.

Следует заметить, что не каждый атрибут класса может характеризовать его состояние. Как правило, имеют значение только такие свойства элементов системы, которые отражают динамический или функциональный аспект ее поведения. В этом случае состояние будет характеризоваться некоторым инвариантным условием, включающим в себя только значимые для поведения класса атрибуты и их значения.

Например, инвариант может представлять статическую ситуацию, когда объект находится в состоянии ожидания возникновения некоторого внешнего события. С другой стороны, инвариант используется для моделирования динамических аспектов, когда в ходе процесса выполняются некоторые действия. В этом случае моделируемый элемент переходит в рассматриваемое состояние в момент начала соответствующей деятельности и покидает данное состояние в момент ее завершения.

Рис. 6.2. Графическое изображение состояний на диаграмме состояний

Состояние на диаграмме изображается прямоугольником со скругленными вершинами (рис. 6.2). Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния (рис. 6.2, а). В противном случае в первой из них записывается имя состояния, а во второй — список некоторых внутренних действий или переходов в данном состоянии (рис. 6.2, б). При этом под действием в языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению состояния или возврату некоторого значения (например, "истина" или "ложь").

Имя состояния

Имя состояния представляет собой строку текста, которая раскрывает содержательный смысл данного состояния. Имя всегда записывается с заглавной буквы. Поскольку состояние системы является составной частью процесса ее функционирования, рекомендуется в качестве имени использовать глаголы в настоящем времени (звенит, печатает, ожидает) или соответствующие причастия (занят, свободен, передано, получено). Имя у состояния может отсутствовать, т. е. оно является необязательным для некоторых состояний. В этом случае состояние является анонимным, и если на диаграмме состояний их несколько, то все они должны различаться между собой.

Список внутренних действий

Эта секция содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Каждое из действий записывается в виде отдельной строки и имеет следующий формат:

<метка-дёйствия '/' выражение-действия>

Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия. При этом выражение действия может использовать любые атрибуты и связи, которые принадлежат области имен или контексту моделируемого объекта. Если список выражений действия пустой, то разделитель в виде наклонной черты '/' может не указываться.

Перечень меток действия имеет фиксированные значения в языке UML, которые не могут быть использованы в качестве имен событий. Эти значения следующие:

  • entry — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие);
  • exit — эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие);
  • do — эта метка специфицирует выполняющуюся деятельность ("do activity"), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия.

В последнем случае при завершении события генерируется соответствующий результат;

  • include — эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата.

Во всех остальных случаях метка действия идентифицирует событие, которое запускает соответствующее выражение действия. Эти события называются внутренними переходами и семантически эквивалентны переходам в само это состояние, за исключением той особенности, что выход из этого состояния или повторный вход в него не происходит. Это означает, что действия входа и выхода не выполняются.

В качестве примера состояния рассмотрим ситуацию ввода пароля пользователя при аутентификации входа в некоторую программную систему (рис. 6.3). В этом случае список внутренних действий в данном состоянии не пуст и включает 4 отдельных действия, первые два из которых стандартные и описаны выше, а два последних определяются своей спецификацией.

Рис. 6.3. Пример состояния с непустой секцией внутренних действий

Начальное состояние

Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний. Графически начальное состояние в языке UML обозначается в виде закрашенного кружка (рис. 6.4, а), из которого может только выходить стрелка, соответствующая переходу.

Рис. 6.4. Графическое изображение начального и конечного состояний на диаграмме состояний

На самом верхнем уровне представления объекта переход из начального состояния может быть помечен событием создания (инициализации) данного объекта. В противном случае переход никак не помечается. Если этот переход не помечен, то он является первым переходом в следующее за ним состояние.

Конечное состояние

Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени. Оно служит для указания на диаграмме состояний графической области, в которой завершается процесс изменения состояний или жизненный цикл данного объекта. Графически конечное состояние в языке UML обозначается в виде закрашенного кружка, помещенного в окружность (рис. 6.4, б), в которую может только входить стрелка, соответствующая переходу.

6.3. Переход

Простой переход (simple transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что переход срабатывает, Или происходит срабатывание перехода. До срабатывания перехода объект находится в предыдущем от него состоянии, называемым исходным состоянием, или в источнике (не путать с начальным состоянием — это разные понятия), а после его срабатывания объект находится в последующем от него состоянии (целевом состоянии).

Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности (do activity), получении объектом сообщения или приемом сигнала. На переходе указывается имя события Кроме того, на переходе могут указываться действия, производимые объектом в ответ на внешние события при переходе из одного состояния в другое. Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение "истина".

Примечание

Переход может быть направлен в то же состояние, из которого он выходит. В этом случае его называют переходом в себя. Исходное и целевое состояния перехода в себя совпадают. Этот переход изображается петлей со стрелкой и отличается от внутреннего перехода. При переходе в себя объект покидает исходное состояние, а затем снова входит в него. При этом всякий раз выполняются внутренние действия, специфицированные метками entry и exit.

На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние (например, "выход из строя" на рис. 6.1). Каждый переход может помечен строкой текста, которая имеет следующий общий формат:

<сигнатура события>'['<сторожевое условие>']' <выражение действия>.

При этом сигнатура события описывает некоторое событие с необходимыми аргументами:

<имя события>'('<список параметров, разделенных запятыми>')'.

Событие

Термин событие (event) требует отдельного пояснения, поскольку является самостоятельным элементом языка UML. Формально, событие представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они "происходят", при этом отдельные события должны быть упорядочены во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели.

Семантика понятия события фиксирует внимание на внешних проявлениях качественных изменений, происходящих при переходе моделируемого объекта из состояния в состояние. Например, при включении электрического переключателя происходит некоторое событие, в результате которого комната становится освещенной. После успешного ремонта компьютера также происходит немаловажное событие — восстановление его работоспособности. Если поднять трубку обычного телефона, то, в случае его исправности, мы ожидаем услышать тоновый сигнал. И этот факт тоже является событием.

В языке UML события играют роль стимулов, которые инициируют переходы из одних состояний в другие. В качестве событий можно рассматривать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий. Имя события идентифицирует каждый отдельный переход на диаграмме состояний и может содержать строку текста, начинающуюся со строчной буквы. В этом случае принято считать переход триггерным, т. е. таким, который специфицирует событие-триггер. Например, переходы на рис. 6.1 являются триггерными, поскольку с каждым из них связано некоторое событие-триггер, происходящее асинхронно в момент выхода из строя технического устройства или в момент окончания его ремонта.

Если рядом со стрелкой перехода не указана никакая строка текста, то соответствующий переход является нетриггерным, и в этом случае из контекста диаграммы состояний должно быть ясно, после окончания какой деятельности он срабатывает. После имени события могут следовать круглые скобки для явного задания параметров соответствующего события-триггера. Если таких параметров нет, то список параметров со скобками может отсутствовать.

Сторожевое условие

Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события-триггера и представляет собой некоторое булевское выражение. Напомним, что булевское выражение должно принимать одно их двух взаимно исключающих значений: "истина" или "ложь". Из контекста диаграммы состояний должна явно следовать семантика этого выражения, а для записи выражения может использоваться синтаксис языка объектных ограничений, основы которого изложены в приложении.

Введение для перехода сторожевого условия позволяет явно специфицировать семантику его срабатывания. Если сторожевое условие принимает значение "истина", то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение "ложь", то переход не может сработать, и при отсутствии других переходов объект не может перейти в целевое состояние по этому переходу. Однако вычисление истинности сторожевого условия происходит только после возникновения ассоциированного с ним события-триггера, инициирующего соответствующий переход.

В общем случае из одного состояния может быть несколько переходов с одним и тем же событием-триггером. При этом никакие два сторожевых условия не должны одновременно принимать значение "истина". Каждое из сторожевых условий необходимо вычислять всякий раз при наступлении соответствующего события-триггера.

Примером события-триггера может служить разрыв телефонного соединения с провайдером Интернет-услуг после окончания загрузки электронной почты клиентской почтовой программой (при удаленном доступе к Интернету). В этом случае сторожевое условие есть не что иное, как ответ на вопрос: "Пуст ли почтовый ящик клиента на сервере провайдера?". В случае положительного ответа "истина", следует отключить соединение с провайдером, что и делает автоматически почтовая программа-клиент. В случае отрицательного ответа "ложь", следует оставаться в состоянии загрузки почты и не разрывать телефонное соединение.

Графически фрагмент логики моделирования почтовой программы может быть представлен в виде следующей диаграммы состояний (рис. 6.5). Как можно заключить из контекста, в начальном состоянии программа не выполняется, хотя и имеется на компьютере пользователя. В момент ее включения происходит ее активизация. В этом состоянии программа может находиться неопределенно долго, пока пользователь ее не закроет, т. е. не выгрузит из оперативной памяти компьютера. После окончания активизации программа переходит в конечное состояние. В активном состоянии программы пользователь может читать сообщения электронной почты, создавать собственные послания и выполнять другие действия, не указанные явно на диаграмме.

Однако при необходимости получить новую почту, пользователь должен установить телефонное соединение с провайдером, что и показано явно на диаграмме верхним переходом. Другими словами, пользователь инициирует событие-триггер "установить телефонное соединение". В качестве параметра этого события выступает конкретный телефонный номер модемного пула провайдера. Далее следует проверка сторожевого условия "телефонное соединение установлено", которое следует понимать как вопрос. Только в случае положительного ответа "да", т. е. "истина", происходит переход почтовой программы-клиента из состояния "активизация почтовой программы" в состояние "загрузка почты с сервера провайдера". В противном случае (линия занята, неверный ввод пароля, отключенный логин) никакой загрузки почты не произойдет, и программа останется в прежнем своем состоянии.

Рис. 6.5. Диаграмма состояний для моделирования почтовой программы-клиента

Второй триггерный переход на диаграмме инициирует автоматический разрыв телефонного соединения с провайдером после окончания загрузки почты на компьютер пользователя. В' этом случае событие-триггер "закончить загрузку почты" происходит после проверки сторожевого условия "почтовый ящик на сервере пуст", которое также следует понимать в форме вопроса. При положительном ответе на этот вопрос (вся почта загружена или ее просто нет в ящике) почтовая программа прекращает загрузку почты и переходит в состояние активизации. В случае же отрицательного ответа загрузка почты будет продолжена.

Примечание

Конечно, рассмотренный пример имеет методический характер и иллюстрирует лишь основные особенности поведения почтовой программы-клиента в одном из ее аспектов. И даже этот аспект загрузки почты во многом условный, поскольку не учитывает реакцию программы на такие сообщения, как "линия занята" или самопроизвольный разрыв соединения.

Речь идет о том, что в отдельных случаях может произойти редкое, но весьма неприятное событие, получившее название "залипание модема". Это характерно для ситуации, когда вся почта загружена, а автоматический разрыв соединения не происходит. Тем не менее и этот случай можно предусмотреть в нашей модели, дополнив диаграмму еще одним переходом с аналогичным событием-триггером "закончить загрузку почты" и с новым сторожевым условием. Это сторожевое условие должно проверять максимально

допустимое время соединения для загрузки почты (например, 600 секунд) и может быть сформулировано в виде "время загрузки почты превышает 600 секунд". Модифицировать диаграмму состояний для этого случая предлагается самостоятельно в качестве упражнения.

Выражение действия

Выражение действия (action expression) выполняется в том и только в том случае, когда переход срабатывает. Представляет собой атомарную операцию (достаточно простое вычисление), выполняемую сразу после срабатывания соответствующего перехода до начала каких бы то ни было действий в целевом состоянии. Атомарность действия означает, что оно не может быть прервано никаким другим действием до тех пор, пока не закончится его выполнение. Данное действие может оказывать влияние как на сам объект, так и на его окружение, если это с очевидностью следует из контекста модели. Выражение записывается после знака "/" в строке текста, присоединенной к соответствующему переходу.

В общем случае, выражение действия может содержать целый список отдельных действий, разделенных символом ";". Обязательное требование — все действия из списка должны четко различаться между собой и следовать в порядке их записи. На синтаксис записи выражений действия не накладывается никаких ограничений. Главное — их запись должна быть понятна разработчикам модели и программистам. Поэтому чаще всего выражения записывают на одном из языков программирования, который предполагается использовать для реализации модели.

В качестве примера выражения действия (см. рис. 6.5) может служить "разорвать телефонное соединение (телефонный номер), которое должно быть выполнено сразу после установления истинности ("истина") сторожевого условия "почтовый ящик на сервере пуст".

Другим примером может служить очевидная ситуация с выделением графических объектов на экране монитора при однократном нажатии левой кнопки мыши. Имеется в виду обработка сигналов от пользователя при выделении тех или иных графических примитивов (пиктограмм). В этом случае соответствующий переход может иметь следующую строку текста: "нажата и отпущена левая кнопка мыши (координаты) [координаты в области графического объекта] / выделить объект (цвет). Результатом этого триггерного перехода может быть, например, активизация некоторых свойств объекта (размер файла в строке состояния) или последующее его удаление в корзину.

Примечание

Иногда после выражения действия может быть записано сообщение в формате: 'Л' <имя объекта приемника сообщения> '.' <имя посылаемого сообщения> '('<параметр>':'<тип>,')'. При этом сообщение имеет чисто информационный характер и не передает управление на объект-приемник сообщения.

6.4. Составное состояние и подсостояние

Составное состояние (composite state) — такое сложное состояние, которое состоит из других вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния (substate). Хотя между ними имеет место отношение композиции, графически все вершины диаграммы, которые соответствуют вложенным состояниям, изображаются внутри символа составного состояния (рис. 6.6). В этом случае размеры графического символа составного состояния увеличиваются, так чтобы вместить в себя все подсостояния.

Рис. 6.6. Графическое представление составного состояния с двумя вложенными в него последовательными подсостояниями

Составное состояние может содержать два или более параллельных подавтомата или несколько последовательных подсостояний. Каждое сложное состояние может уточняться только одним из указанных способов. При этом любое из подсостояний, в свою очередь, может являться составным состоянием и содержать внутри себя другие вложенные подсостояния. Количество уровней вложенности составных состояний не фиксировано в языке UML.

Последовательные подсостояния

Последовательные подсостояния (sequential substates) используются для моделирования такого поведения объекта, во время которого в каждый момент времени объект может находиться в одном и только одном подсостояний. Поведение объекта в этом случае представляет собой последовательную смену подсостояний, начиная от начального и заканчивая конечным подсостояниями. Хотя объект продолжает находиться в составном состоянии, введение в рассмотрение последовательных подсостояний позволяет учесть более тонкие логические аспекты его внутреннего поведения.

Для примера рассмотрим в качестве моделируемого объекта обычный телефонный аппарат. Он может находиться в различных состояниях, одним из которых является состояние дозвона до абонента. Очевидно, для того чтобы позвонить, необходимо снять телефонную трубку, услышать тоновый сигнал, после чего набрать нужный телефонный номер. Таким образом, состояние дозвона до абонента является составным и состоит из двух последовательных подсостояний: "поднять телефонную трубку" и "набрать телефонный номер". Фрагмент диаграммы состояний для этого примера содержит одно составное состояние и два последовательных подсостояний (рис. 6.7).

Рис. 6.7. Пример составного состояния с двумя вложенными последовательными подсостояниями

Некоторых пояснений могут потребовать переходы. Два из них специфицируют событие-триггер набор цифры, которое имеет имя "цифра" с параметром "п". В качестве параметра, как нетрудно предположить, выступает отдельная цифра на диске телефонного аппарата. Переход из начального под-состояния нетриггерный, поскольку он не содержит никакой строки текста. Последний переход в конечное подсостояние не имеет события-триггера, но имеет сторожевое условие, проверяющее правильность набранного номера абонента. Только в случае истинности этого условия телефонный аппарат может перейти в конечное подсостояние, которое характеризует суперсостояние "дозвон до абонента" в целом.

Составное состояние может содержать в качестве вложенных подсостояний начальное и конечное состояния. При этом начальное подсостояние является исходным, когда происходит переход объекта в данное составное состояние. Если составное состояние содержит внутри себя конечное подсостояние, то переход в это вложенное конечное состояние означает завершение нахождения объекта в данном вложенном состоянии. Важно помнить, что для последовательных подсостояний начальное и конечное состояния должны быть единственными в каждом составном состоянии.

Это можно объяснить следующим образом. Каждая совокупность вложенных последовательных подсостояний представляет собой подавтомат того автомата, которому принадлежит рассматриваемое составное состояние. Поскольку каждый автомат может иметь по определению единственное начальное и единственное конечное состояния, то для подавтомата это условие также должно выполняться (рис. 6.7).

Параллельные подсостояния

Параллельные подсостояния (concurrent substates) позволяют специфицировать два и более подавтомата, которые могут выполняться параллельно внутри составного события. Каждый из подавтоматов занимает некоторую область (регион) внутри составного состояния, которая отделяется от остальных горизонтальной пунктирной линией. Если на диаграмме состояний имеется составное состояние с вложенными параллельными подсостояниями, то объект может одновременно находиться в каждом из этих подсостояний.

Однако отдельные параллельные подсостояния могут, в свою очередь, состоять из нескольких последовательных подсостояний (подавтоматы 1 и 2 на рис. 6.8). В этом случае по определению объект может находиться только в одном из последовательных подсостояний подавтомата. Таким образом, для абстрактного примера (рис. 6.8) допустимо одновременное нахождение объекта в подсостояниях (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Недопустимо нахождение объекта одновременно в подсостояниях (1, 2,3) или (3, 4, 5).

Рис. 6.8. Графическое изображение составного состояния с вложенными параллельными подсостояниями

Поскольку каждый регион вложенного состояния специфицирует некоторый подавтомат, то для каждого из вложенных подавтоматов могут быть определены собственные начальное и конечные подсостояния (рис. 6.8). При переходе в данное составное состояние каждый из подавтоматов оказывается в своем начальном подсостояний. Далее происходит параллельное выполнение каждого из этих подавтоматов, причем выход из составного состояния будет возможен лишь в том случае, когда все подавтоматы будут находиться в своих конечных подсостояниях.

Если какой-либо из подавтоматов пришел в свое конечное состояние раньше других, то он должен ожидать, пока и другие подавтоматы не придут в свои конечные состояния.

В некоторых случаях бывает желательно скрыть внутреннюю структуру составного состояния. Например, отдельный подавтомат, специфицирующий составное состояние, может быть настолько большим по масштабу, что его визуализация затруднит общее представление диаграммы состояний. В подобной ситуации допускается не раскрывать на исходной диаграмме состояний данное составное состояние, а указать в правом нижнем углу специальный символ-пиктограмму (рис. 6.9). В последующем диаграмма состояний для соответствующего подавтомата может быть изображена отдельно от основной с необходимыми комментариями.

Рис. 6.9. Составное состояние со скрытой внутренней структурой и специальной пиктограммой

6.5. Историческое состояние

Как было отмечено выше, формализм обычного автомата не позволяет учитывать предысторию в процессе моделирования поведения объектов. Однако функционирование целого ряда систем основано на возможности выхода из отдельных состояний с последующим возвращением в это же состояние. При этом может оказаться необходимым учесть ту часть деятельности, которая была выполнена на момент выхода из этого состоянии, чтобы не начинать ее выполнение сначала. Для этой цели в языке UML существует историческое состояние.

Историческое состояние (history state) применяется в контексте составного состояния. Оно используется для запоминания того из последовательных подсостояний, которое было текущим в момент выхода из составного состояния. При этом существует две разновидности исторического состояния: недавнее и давнее (рис. 6.10).

Рис. 6.10. Графическое изображение недавнего (а) и давнего (б) исторического состояния

Недавнее историческое состояние (shallow history state) обозначается в форме небольшой окружности, в которую помещена латинская буква "Н" (рис. 6.10, а). Это состояние обладает следующей семантикой. Во-первых, оно является первым подсостоянием в составном состоянии, и переход извне в это составное состояние должен вести непосредственно в это историческое состояние. Во-вторых, при первом попадании в недавнее историческое состояние оно не хранит никакой истории (история пуста). Другими словами, при первом переходе в недавнее историческое состояние оно заменяет собой начальное состояние подавтомата.

Далее следует последовательное изменение вложенных подсостояний. Если в некоторый момент происходит выход из вложенного состояния (например, в случае некоторого внешнего события), то это историческое состояние запоминает то из подсостояний, которое являлось текущим на момент выхода. При следующем входе в это же составное состояние историческое подсостояние уже имеет непустую историю и сразу отправляет подавтомат в запомненное подсостояние, минуя все предшествующие ему подсостояния.

Историческое состояние теряет свою историю в тот момент, когда подавтомат доходит до своего конечного состояния. При этом недавнее историческое состояние запоминает историю только того подавтомата, к которому он относится. Другими словами, этот тип состояния способен запомнить историю только одного с ним уровня вложенности.

С другой стороны, запомненное состояние, в свою очередь, также может являться составным состоянием. Давнее историческое состояние (deep history state) обозначается в форме небольшой окружности, в которую помещена латинская буква "Н" с символом "*" (рис. 6.10, б) и служит для запоминания всех подсостояний любого уровня вложенности для текущего подавтомата.

Простым примером, иллюстрирующем применение недавнего исторического состояния, может служить логика работы почтовой программы-клиента. Предположим, при запуске этой программы мы находимся в состоянии написания нового сообщения, причем набран уже значительный фрагмент текста. Почтовая программа может быть сконфигурирована таким образом, что в фиксированные моменты времени (например, каждые 30 минут) она проверяет наличие новых сообщений на сервере провайдера при удаленном доступе. Очевидно, что очередной дозвон, хотя и прерывает работу редактора, не должен привести к потере набранного фрагмента текста.

В этом случае составное состояние "работа редактора" должно содержать вложенное историческое подсостояние, которое запоминает выполненную работу. После окончания дозвона и загрузки новой почты (в случае ее наличия) мы должны вернуться к сохраненному фрагменту нашего сообщения и продолжить работу редактора программы.

Диаграмма состояний почтовой программы-клиента (см. рис. 6.5) может быть дополнена с учетом рассмотренного аспекта ее поведения. Читателю предлагается это проделать самостоятельно в качестве упражнения.

6.6. Сложные переходы

Рассмотренное выше понятие перехода является вполне достаточным для большинства типичных расчетно-вычислительных задач. Однако современные программные системы могут реализовывать очень сложную логику поведения отдельных своих компонентов. Может оказаться, что для адекватного представления процесса изменения состояний семантика обычного перехода для них недостаточна. С этой целью в языке UML специфицированы дополнительные обозначения и свойства, которыми могут обладать отдельные переходы на диаграмме состояний.

Переходы между параллельными состояниями

В отдельных случаях переход может иметь несколько состояний-источников и несколько целевых состояний. Такой переход получил специальное название — параллельный переход. Введение в рассмотрение параллельного перехода обусловлено необходимостью синхронизировать и/или разделить отдельные подпроцессы на параллельные нити без спецификации дополнительной синхронизации в параллельных подавтоматах.

Графически такой переход изображается вертикальной черточкой, аналогично обозначению перехода в известном формализме сетей Петри. Если параллельный переход имеет две или более входящих дуг (рис. 6.11, а), то его называют соединением (join). Если же он имеет две или более исходящих из него дуг (рис. 6.11, б), то его называют ветвлением (fork). Текстовая строка спецификации параллельного перехода записывается рядом с черточкой и относится ко всем входящим (исходящим) дугам.

Рис. 6.11. Графическое изображение параллельного перехода из параллельных состояний (а) и параллельного перехода в параллельные состояния (б)

Срабатывание параллельного перехода происходит следующим образом. В первом случае (переход-соединение) переход срабатывает, если имеет место событие-триггер для всех исходных состояний этого перехода, и выполнено (при его наличии) сторожевое условие. При срабатывании перехода-соединения одновременно покидаются все исходные состояния перехода (состояния 1 и 2) и происходит переход в целевое состояние. При этом каждое из исходных состояний перехода должно принадлежать отдельному подавтомату, входящему в состав автомата (процессу 1).

Во втором случае (ветвление) происходит расщепление автомата на два подавтомата, образующих параллельные ветви вложенных подсостояний. При этом после срабатывания перехода моделируемый объект одновременно будет находиться во всех целевых состояниях этого перехода (состояния 3 и 4). Далее процесс изменения состояний будет протекать согласно ранее рассмотренным правилам для составных состояний.

Переходы между составными состояниями

Переход, стрелка которого соединена с границей некоторого составного состояния, обозначает переход в составное состояние (переход b на рис. 6.12). Он эквивалентен переходу в начальное состояние каждого из подавтоматов (возможно, единственному), входящих в состав данного суперсостояния. Переход, выходящий из составного состояния (переходы f и g на рис. 6.12), относится к каждому из вложенных подсостояний. Это означает, что объект может покинуть составное суперсостояние, находясь в любом из его подсостояний. Для этого вполне достаточно выполнения события и сторожевого условия.

Рис. 6.12. Различные варианты переходов в (из) составное состояние

Иногда желательно реализовать ситуацию, когда выход из отдельного вложенного состояния соответствовал бы выходу и из составного состояния тоже. В этом случае изображают переход, который непосредственно выходит из вложенного подсостояния за границу суперсостояния (переход с на рис. 6.12). Аналогично, допускается изображение переходов, входящих извне составного состояния в отдельное вложенное состояние (переход а на рис. 6.12).

Синхронизирующие состояния

Как уже было отмечено, поведение параллельных подавтоматов независимо друг от друга, что позволяет реализовать многозадачность в программных системах. Однако в отдельных случаях может возникнуть необходимость учесть в модели синхронизацию наступления отдельных событий. Для этой цели в языке UML имеется специальное псевдосостояние, которое называется синхронизирующим состоянием.

Синхронизирующее состояние (synch state) обозначается небольшой окружностью, внутри которой помещен символ звездочки "*". Оно используется совместно с переходом-соединением или переходом-ветвлением для того, чтобы явно указать события в других подавтоматах, оказывающие непосредственное влияние на поведение данного подавтомата.

Для иллюстрации использования синхронизирующих состояний рассмотрим упрощенную ситуацию с моделированием процесса постройки дома. Предположим, что постройка дома включает в себя строительные работы (возведение фундамента и стен, возведение крыши и отделочные работы) и работы по электрификации дома (подведение электрической линии, прокладка скрытой электропроводки и установка осветительных ламп). Очевидно, два этих комплекса работ могут выполняться параллельно, однако между ними есть некоторая взаимосвязь.

В частности, прокладка скрытой электропроводки может начаться лишь после того, как будет завершено возведение фундамента и стен. А отделочные работы следует начать лишь после того, как будет закончена прокладка скрытой электропроводки. В противном случае отделочные работы придется проводить повторно. Рассмотренные особенности синхронизации этих параллельных процессов учтены на соответствующей диаграмме состояний с помощью двух синхронизирующих состояний (рис. 6.13).

Рис. 6.13. Диаграмма состояний для примера со строительством дома

В завершение этого раздела рассмотрим диаграмму состояний, которая представляет собой пример моделирования поведения конкретного объекта — процесса функционирования телефонного аппарата (рис. 6.14). Этот пример иллюстрирует все основные особенности графической нотации, используемой при построении диаграммы состояний.

Кратко прокомментируем основные особенности этого примера. Данная диаграмма состояний представляет единственный автомат с одним составным состоянием. Вне этого составного состояния имеется только одно состояние "ожидание", которое характеризует исправный и подключенный к телефонной сети телефонный аппарат. Переход в следующее состояние происходит при поднятии телефонной трубки. Переход с атомарным действием "подать тоновый сигнал" переводит аппарат в составное состояние, а точнее — в начальное его подсостояние.

Рис. 6.14. Диаграмма состояний процесса функционирования телефонного аппарата

Далее телефонный аппарат будет находиться в состоянии "тоновый сигнал". При этом будет непрерывно издавать этот сигнал до тех пор, пока не произойдет событие-триггер "набор цифры (п)", либо не истечет 15 секунд с момента поднятия трубки. В первом случае аппарат перейдет в состояние "набор номера", а во втором — в состояние "истечение времени ожидания". Последняя ситуация может быть результатом сомнений по поводу "звонить — не звонить?", следствием чего могут стать гудки в трубке. При этом нам ничего не остается делать, как опустить ее на рычаг.

При наборе номера выполняется событие-триггер "набор цифры (п) со сторожевым условием "номер неполный". Это означает, что если набранный телефонный номер не содержит необходимого количества цифр, то нам следует продолжать набор очередной цифры, оставаясь в состоянии "набор номера".

Если же набранный номер полный, то можно перейти в состояние "неверный номер" или "соединение". В случае неверного номера (сторожевое условие "неверный" истинно) ничего не остается, как покинуть составное состояние, опустив трубку на рычаг. Если же номер верный, то происходит соединение по этому номеру.

Однако в результате соединения может оказаться, что аппарат абонента занят (переход в состояние "занято") либо свободен (переход в состояние "звонок у абонента"). В первом случае можно повторить дозвон, предварительно опустив трубку на рычаг (выход из составного состояния). Во втором случае происходит проверка сторожевого условия "разговор доступен". Если оно истинно, что соответствует снятию трубки абонентом, начинается телефонный разговор. В противном случае (это условие не выполняется, т. е. оно ложно) телефон абонента будет продолжать звонить, извещая нас об отсутствии последнего либо о невозможности по какой-либо причине вести разговор по телефону. При этом нам ничего не остается, как опустить трубку на рычаг.

Если же разговор состоялся, то после слов прощания и выполнения сторожевого условия "подтверждение" на окончание разговора мы снова опускаем трубку. При этом телефонный аппарат переходит в состояние "ожидание", в котором может находиться неопределенно долго.

Примечание

Строго говоря, рассмотренный пример отражает не все аспекты поведения даже такого несложного на первый взгляд устройства, каким является обычный телефонный аппарат. В частности, данная диаграмма состояний может быть дополнена переходом из состояния "ожидание" по событию-триггеру "телефонный звонок", который может сразу перевести нас во внутреннее подсостояние "разговор", если мы решили снять телефонную трубку (переход типа а на рис. 6.12).

Другая модификация может быть связана с желанием повторно использовать набранный номер в случае коротких гудков "занято" у абонента. Решение этой задачи может быть реализовано на основе использования исторического состояния вместо начального подсостояния, которое будет запоминать в памяти аппарата единожды набранный номер. Дополнить диаграмму состояний читателю предлагается самостоятельно в качестве упражнения.

6.7. Заключительные рекомендации по построению диаграмм состояний

Основные особенности построения диаграмм состояний были рассмотрены при описании соответствующих модельных элементов, входящих в пакет Автоматы. Однако некоторые моменты не нашли отражения, о чем необходимо сказать в заключение этой главы.

По своему назначению диаграмма состояний не является обязательным представлением в модели и как бы "присоединяется" к тому элементу, который, по замыслу разработчиков, имеет нетривиальное поведение в течение своего жизненного цикла. Наличие у системы нескольких состояний, отличающихся от простой дихотомии "исправен — неисправен", "активен — неактивен", "ожидание — реакция на внешние действия", уже служит признаком необходимости построения диаграммы состояний. В качестве начального варианта диаграммы состояний, если нет очевидных соображений по поводу состояний объекта, можно воспользоваться этими суперсостояниями, рассматривая их как составные и уточняя их (детализируя их внутреннюю структуру) по мере рассмотрения логики поведения объекта.

При выделении состояний и переходов следует помнить, что длительность срабатывания отдельных переходов должна быть существенно меньшей, чем нахождение моделируемого объекта в соответствующих состояниях. Каждое из состояний должно характеризоваться определенной устойчивостью во времени. Другими словами, из каждого состояния на диаграмме не может быть самопроизвольного перехода в какое бы то ни было другое состояние. Все переходы должны быть явно специфицированы, в противном случае построенная диаграмма состояний является либо неполной, либо ошибочной.

При разработке диаграммы состояний нужно постоянно следить, чтобы объект в каждый момент мог находиться только в единственном состоянии. Если это не так, то данное обстоятельство может быть как следствием ошибки, так и неявным признаком наличия параллельности у поведения моделируемого объекта. В последнем случае следует явно специфицировать необходимое число подавтоматов, вложив их в то составное состояние, которое характеризуется нарушением условия одновременности.

Следует обязательно проверять, что никакие два перехода из одного состояния не могут сработать одновременно (требование отсутствия конфликтов у переходов). Наличие такого конфликта может служить признаком ошибки либо неявной параллельности типа ветвления рассматриваемого процесса на два и более подавтомата. Если параллельность по замыслу разработчика отсутствует, то необходимо ввести дополнительные сторожевые условия либо изменить существующие, чтобы исключить конфликт переходов. При наличии параллельности следует заменить конфликтующие переходы одним параллельным переходом типа ветвления.

Использование исторических состояний оправдано в том случае, когда необходимо организовать обработку исключительных ситуаций (прерываний) без потери данных или выполненной работы. При этом применять исторические состояния, особенно глубокие, надо с известной долей осторожности. Нужно помнить, что каждый из подавтоматов может иметь только одно историческое состояние. В противном случае возможны ошибки, особенно когда подавтоматы изображаются на отдельных диаграммах состояний.

И, наконец, следует отметить, что некоторые дополнительные конструкции автоматов, такие как точки динамического выбора (dynamic choice points) или точки соединения (junction points), в книге не нашли отражения. Это сделано по той причине, что данные модельные элементы хотя и позволяют моделировать более сложные аспекты динамического управления поведением объекта, не являются базовыми. Соответствующая информация содержится в оригинальной документации по языку UML.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 7
Диаграмма деятельности (activity diagram)

  • 7.1. Состояние действия
  • 7.2. Переходы
  • 7.3. Дорожки
  • 7.4. Объекты
  • 7.5. Рекомендации по построению диаграмм деятельности

При моделировании поведения проектируемой или анализируемой системы возникает необходимость не только представить процесс изменения ее состояний, но и детализировать особенности алгоритмической и логической реализации выполняемых системой операций. Традиционно для этой цели использовались блок-схемы или структурные схемы алгоритмов (такие как, например, на рис. 1.1). Каждая такая схема акцентирует внимание на последовательности выполнения определенных действий или элементарных операций, которые в совокупности приводят к получению желаемого результата.

Алгоритмические и логические операции, требующие выполнения в определенной последовательности, окружают нас постоянно. Конечно, мы не всегда задумываемся о том, что подобные операции относятся к столь научным категориям. Например, чтобы позвонить по телефону, нам предварительно нужно снять трубку или включить его. Для приготовления кофе или заваривания чая необходимо вначале вскипятить воду. Чтобы выполнить ремонт двигателя автомобиля, требуется осуществить целый ряд нетривиальных операций, таких как разборка силового агрегата, снятие генератора и некоторых других.

Важно подчеркнуть то обстоятельство, что с увеличением сложности системы строгое соблюдение последовательности выполняемых операций приобретает все более важное значение. Если попытаться заварить кофе холодной водой, то мы можем только испортить одну порцию напитка. Нарушение последовательности операций при ремонте двигателя может привести к его поломке или выходу из строя. Еще более катастрофические последствия могут произойти в случае отклонения от установленной последовательности действий при взлете или посадке авиалайнера, запуске ракеты, регламентных работах на АЭС.

Для моделирования процесса выполнения операций в языке UML используются так называемые диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения состояний и переходов. Отличие заключается в семантике состояний, которые используются для представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий. Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной операции, а переход в следующее состояние срабатывает только при завершении этой, операции в предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами — переходы от одного состояния действия к другому.

Таким образом, диаграммы деятельности можно считать частным случаем диаграмм состояний. Именно они позволяют реализовать в языке UML особенности процедурного и синхронного управления, обусловленного завершением внутренних деятельностей и действий. Метамодель UML предоставляет для этого необходимые термины и семантику. Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения. При этом каждое состояние может являться выполнением операции некоторого класса либо ее части, позволяя использовать диаграммы деятельности для описания реакций на внутренние события системы.

В контексте языка UML деятельность (activity) представляет собой некоторую совокупность отдельных вычислений, выполняемых автоматом. При этом отдельные элементарные вычисления могут приводить к некоторому результату или действию (action). На диаграмме деятельности отображается логика или последовательность перехода от одной деятельности к другой, при этом внимание фиксируется на результате деятельности. Сам же результат может привести к изменению состояния системы или возвращению некоторого значения.

Примечание

Хотя диаграмма деятельности предназначена для моделирования поведения систем, время в явном виде отсутствует на этой диаграмме. Ситуация здесь во многом аналогична диаграмме состояний.

7.1. Состояние действия

Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия не может иметь внутренних переходов, поскольку оно является элементарным. Обычное использование состояния действия заключается в моделировании одного шага выполнения алгоритма (процедуры) или потока управления.

Графически состояние действия изображается фигурой, напоминающей прямоугольник, боковые стороны которого заменены выпуклыми дугами (рис. 7.1). Внутри этой фигуры записывается выражение действия (action-expression), которое должно быть уникальным в пределах одной диаграммы деятельности.

Рис. 7.1. Графическое изображение состояния действия

Действие может быть записано на естественном языке, некотором псевдокоде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами (рис. 7.1, а). Если же действие может быть представлено в некотором формальном виде, то целесообразно записать его на том языке программирования, на котором предполагается реализовывать конкретный проект (рис. 7.1, б).

Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное действие, которое, в свою очередь, состоит из нескольких более простых действий. В этом случае можно использовать специальное обозначение так называемого состояния под-деятельности (subactivity state). Такое состояние является графом деятельности и обозначается специальной пиктограммой в правом нижнем углу символа состояния действия (рис. 7.2). Эта конструкция может применяться к любому элементу языка UML, который поддерживает "вложенность" своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.

Рис. 7.2. Графическое изображение состояния под-деятельности

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. Они имеют такие же обозначения, как и на диаграмме состояний (см. рис. 6.4). При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы действия следовали сверху вниз. В этом случае начальное состояние будет изображаться в верхней части диаграммы, а конечное — в ее нижней части.

7.2. Переходы

Переход как элемент языка UML был рассмотрен в главе 6. При построении диаграммы деятельности используются только нетриггерные переходы, т. е. такие, которые срабатывают сразу после завершения деятельности или выполнения соответствующего действия. Этот переход переводит деятельность в последующее состояние сразу, как только закончится действие в предыдущем состоянии. На диаграмме такой переход изображается сплошной линией со стрелкой.

Если из состояния действия выходит единственный переход, то он может быть никак не помечен. Если же таких переходов несколько, то сработать может только один из них. Именно в этом случае для каждого из таких переходов должно быть явно записано сторожевое условие в прямых скобках (см. главу 6). При этом для всех выходящих из некоторого состояния переходов должно выполняться требование истинности только одного из них. Подобный случай встречается тогда, когда последовательно выполняемая деятельность должна разделиться на альтернативные ветви в зависимости от значения некоторого промежуточного результата. Такая ситуация получила название ветвления, а для ее обозначения применяется специальный символ.

Графически ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 7.3). В этот ромб может входить только одна стрелка от того состояния действия, после выполнения которого поток управления должен быть продолжен по одной из взаимно исключающих ветвей. Принято входящую стрелку присоединять к верхней или левой вершине символа ветвления. Выходящих стрелок может быть две или более, но для каждой из них явно указывается соответствующее сторожевое условие в форме булевского выражения.

В качестве примера рассмотрим фрагмент известного алгоритма нахождения корней квадратного уравнения. В общем случае после приведения уравнения второй степени к каноническому виду: а*х*х + Ь*х + с = 0 необходимо вычислить его дискриминант. Причем, в случае отрицательного дискриминанта уравнение не имеет решения на множестве действительных чисел, и дальнейшие вычисления должны быть прекращены. При неотрицательном дискриминанте уравнение имеет решение, корни которого могут быть получены на основе конкретной расчетной формулы. .

Графически фрагмент процедуры вычисления корней квадратного уравнения может быть представлен в виде диаграммы деятельности с тремя состояниями действия и ветвлением (рис. 7.3). Каждый из переходов, выходящих из состояния "Вычислить дискриминант", имеет сторожевое условие, определяющее единственную ветвь, по которой может быть продолжен процесс вычисления корней в зависимости от знака дискриминанта. Очевидно, что в случае его отрицательности, мы сразу попадаем в конечное состояние, тем самым завершая выполнение алгоритма в целом.

Примечание

Строго говоря, первое из состояний рассматриваемого алгоритма следует считать состоянием под-деятельности, поскольку приведение квадратного уравнения к каноническому виду может потребовать нескольких элементарных действий (приведение подобных и перенос отдельных членов уравнения из правой его части в левую). Поэтому для данного состояния целесообразно добавить соответствующую пиктограмму (как на рис. 7.2).

Рис. 7.3. Фрагмент диаграммы деятельности для алгоритма нахождения корней квадратного уравнения

В рассмотренном примере, как видно из рис. 7.3, выполняемые действия соединяются в конечном состоянии. Однако это вовсе не является обязательным. Можно изобразить еще один символ ветвления, который будет иметь несколько входящих переходов и один выходящий.

В следующем примере (рис. 7.4) рассчитывается общая стоимость товаров, покупаемых по кредитной карточке в супермаркете. Если эта стоимость превышает $50, то выполняется аутентификация личности владельца карточки. В случае положительной проверки (карточка действительная) или если стоимость товаров не превышает $50, происходит снятие суммы со счета и оплата стоимости товаров. При отрицательном результате (карточка недействительная) оплаты не происходит, и товар остается у продавца.

Примечание

Как видно из этого же рисунка, допускается использовать вместо сторожевого условия слово "иначе", указывающее на тот переход, который должен сработать в случае невыполнения сторожевого условия ветвления.

Рис. 7.4. Различные варианты ветвлений на диаграмме деятельности

Один из наиболее значимых недостатков обычных блок-схем или структурных схем алгоритмов связан с проблемой изображения параллельных ветвей отдельных вычислений. Поскольку распараллеливание вычислений существенно повышает общее быстродействие программных систем, необходимы графические примитивы для представления параллельных процессов. В языке UML для этой цели используется специальный символ для разделения и слияния параллельных вычислений или потоков управления. Таким символом является прямая черточка, аналогично обозначению перехода в формализме сетей Петри.

Как правило, такая черточка изображается отрезком горизонтальной линии, толщина которой несколько шире основных сплошных линий диаграммы деятельности. При этом разделение (concurrent fork) имеет один входящий переход и несколько выходящих (рис. 7.5, а). Слияние (concurrent join), наоборот, имеет несколько входящих переходов и один выходящий (рис. 7.5, б).

Для иллюстрации особенностей параллельных процессов выполнения действий рассмотрим ставший уже классическим пример с приготовлением напитка. Достоинство этого примера состоит в том, что он практически не требует никаких дополнительных пояснений в силу своей очевидности (рис. 7.6).

Рис. 7.5. Графическое изображение разделения и слияния параллельных потоков управления

Рис. 7.6. Диаграмма деятельности для примера с приготовлением напитка

Примечание

Наличие параллельности проявляется в том, что мы можем заняться поисками чашки во время приготовления кофе. Впрочем, поскольку выбор конкретных напитков остается за читателем, разработка соответствующей диаграммы деятельности может быть предложена в качестве упражнения.

Таким образом, диаграмма деятельности есть не что иное, как специальный случай диаграммы состояний, в которой все или большинство состояний являются действиями или состояниями под-деятельности. А все или большинство переходов являются нетригтерными переходами, которые срабатывают по завершении действий или под-деятельностей в состояниях-источниках.

7.3. Дорожки

Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов вычислений или потоков управления в программных системах. Не менее важная область их применения связана с моделированием бизнес-процессов. Действительно, деятельность любой компании (фирмы) также представляет собой не что иное, как совокупность отдельных действий, направленных на достижение требуемого результата. Однако применительно к бизнес-процессам желательно выполнение каждого действия ассоциировать с конкретным подразделением компании. В этом случае подразделение несет ответственность за реализацию отдельных действий, а сам бизнес-процесс представляется в виде переходов действий из одного подразделения к другому.

Для моделирования этих особенностей в языке UML используется специальная конструкция, получившее название дорожки (swimlanes). Имеется в виду визуальная аналогия с плавательными дорожками в бассейне, если смотреть на соответствующую диаграмму. При этом все состояния действия на диаграмме деятельности делятся на отдельные группы, которые отделяются друг от друга вертикальными линиями. Две соседние линии и образуют дорожку, а группа состояний между этими линиями выполняется отдельным подразделением (отделом, группой, отделением, филиалом) компании (рис. 7.7).

Названия подразделений явно указываются в верхней части дорожки. Пересекать линию дорожки могут только переходы, которые в этом случае обозначают выход или вход потока управления в соответствующее подразделение компании. Порядок следования дорожек не несет какой-либо семантической информации и определяется соображениями удобства.

В качестве примера рассмотрим фрагмент диаграммы деятельности торговой компании, обслуживающей клиентов по телефону. Подразделениями компании являются отдел приема и оформления заказов, отдел продаж и склад.

Этим подразделениям будут соответствовать три дорожки на диаграмме деятельности, каждая из которых специфицирует зону ответственности подразделения. В данном случае диаграмма деятельности заключает в себе не только информацию о последовательности выполнения рабочих действий, но и о том, какое из подразделений торговой компании должно выполнять то или иное действие (рис. 7.8).

Рис. 7.7. Вариант диаграммы деятельности с дорожками

Рис. 7.8. Фрагмент диаграммы деятельности для торговой компании

Из указанной диаграммы деятельности сразу видно, что после принятия заказа от клиента отделом приема и оформления заказов осуществляется распараллеливание деятельности на два потока (переход-разделение). Первый из них остается в этом же отделе и связан с получением оплаты от клиента за заказанный товар. Второй инициирует выполнение действия по подбору товара в отделе продаж (модель товара, размеры, цвет, год выпуска и пр.). По окончании этой работы инициируется действие по отпуску товара со склада. Однако подготовка товара к отправке в торговом отделе начинается только после того, как будет получена оплата за товар от клиента и товар будет отпущен со склада (переход-соединение). Только после этого товар отправляется клиенту, переходя в его собственность.

7.4. Объекты

В общем случае действия на диаграмме деятельности выполняются над теми или иными объектами. Эти объекты либо инициируют выполнение действий, либо определяют некоторый результат этих действий. При этом действия специфицируют вызовы, которые передаются от одного объекта графа деятельности к другому. Поскольку в таком ракурсе объекты играют определенную роль в понимании процесса деятельности, иногда возникает необходимость явно указать их на диаграмме деятельности.

Для графического представления объектов, как уже упоминалось в главе 5, используются прямоугольник класса, с тем отличием, что имя объекта подчеркивается. Далее после имени может указываться характеристика состояния объекта в прямых скобках. Такие прямоугольники объектов присоединяются к состояниям действия отношением зависимости пунктирной линией со стрелкой. Соответствующая зависимость определяет состояние конкретного объекта после выполнения предшествующего действия.

На диаграмме деятельности с дорожками расположение объекта может иметь некоторый дополнительный смысл. А именно, если объект расположен на границе двух дорожек, то это может означать, что переход к следующему состоянию действия в соседней дорожке ассоциирован с готовностью некоторого документа (объект в некотором состоянии). Если же объект целиком расположен внутри дорожки, то и состояние этого объекта целиком определяется действиями данной дорожки.

Возвращаясь к предыдущему примеру с торговой компанией, можно заметить, что центральным объектом процесса продажи является заказ или вернее состояние его выполнения. Вначале до звонка от клиента заказ как объект отсутствует и возникает лишь после такого звонка. Однако этот заказ еще не заполнен до конца, поскольку требуется еще подобрать конкретный товар в отделе продаж. После его подготовки он передается на склад, где вместе с отпуском товара заказ окончательно дооформляется. Наконец, после получения подтверждения об оплате товара эта информация заносится в заказ, и он считается выполненным и закрытым. Данная информация может быть представлена графически в виде модифицированного варианта диаграммы деятельности этой же торговой компании (рис. 7.9).

Примечание

Более подробно правила именования объектов и их использования будут рассмотрены при построении диаграммы кооперации в главе 9. Что касается диаграмм деятельности, то применительно к ним объекты играют вспомогательную роль и поэтому здесь детально не рассматриваются. Следует также помнить, что на диаграмме деятельности один и тот же объект может быть изображен несколько раз, что не должно вносить неопределенность в спецификацию состояний действия.

Рис. 7.9. Фрагмент диаграммы деятельности торговой компании с объектом-заказом

В заключение следует остановиться на необходимости синхронизации отдельных действий на диаграмме деятельности. Такая необходимость возникает всякий раз, когда параллельно выполняемые действия оказывают влияние на друг на друга. Если вспомнить материал главы 6, то применительно к диаграмме состояний для этой цели применялось специальное псевдосостояние — синхронизирующее состояние. На диаграмме деятельности никаких дополнительных обозначений не используется, поскольку синхронизация параллельных процессов может быть реализована с помощью переходов "разделение-слияние".

В качестве примера рассмотрим упрощенную ситуацию с моделированием процесса постройки дома (см. главу 6). Напомним, что в этом примере постройка дома включает в себя строительные работы (возведение фундамента и стен, возведение крыши и отделочные работы) и работы по электрификации дома (подведение электрической линии, прокладка скрытой электропроводки и установка осветительных ламп). Синхронизация параллельного выполнения этого комплекса работ может быть явно указана на диаграмме деятельности (рис. 7.10).

Рис. 7.10. Диаграмма деятельности с синхронизацией параллельных действий

В рассмотренном примере все состояния являются состояниями под-деятельности. Это означает, что каждое из них можно детализировать в виде отдельного графа деятельности с соответствующей диаграммой. Действительно, состояние под-деятельности "Подготовка участка" может включать в себя такие действия, как очистка участка от деревьев, вывоз этих деревьев за пределы участка, рытье котлована под фундамент, установка временных строений для складирования строительных материалов и другие работы.

Впрочем, некоторые из состояний могут быть и простыми состояниями действия, в случае если соответствующая работа превращается в выполнение элементарного действия, неразложимого на отдельные операции или приемы.

7.5. Рекомендации по построению диаграмм деятельности

Диаграммы деятельности играют важную роль в понимании процессов реализации алгоритмов выполнения операций классов и потоков управления в моделируемой системе. Используемые для этой цели традиционные блок-схемы алгоритмов обладают серьёзными ограничениями в представлении параллельных процессов и их синхронизации. Применение дорожек и объектов открывает дополнительные возможности для наглядного представления бизнес-процессов, позволяя специфицировать деятельность подразделений компаний и фирм.

Содержание диаграммы деятельности во многом напоминает диаграмму состояний, хотя и не тождественно ей. Поэтому многие рекомендации по построению последней оказываются справедливыми применительно к диаграмме деятельности. В частности, эта диаграмма строится для отдельного класса, варианта использования, отдельной операции класса или целой подсистемы.

С одной стороны, на начальных этапах проектирования, когда детали реализации деятельностей в проектируемой системе неизвестны, построение диаграммы деятельности начинают с выделения под-деятельностей, которые в совокупности образуют деятельность подсистем. В последующем, по мере разработки диаграмм классов и состояний, эти под-деятельности уточняются в виде отдельных вложенных диаграмм деятельности компонентов подсистем, какими выступают классы и объекты.

С другой стороны, отдельные участки рабочего процесса в существующей системе могут быть хорошо отлаженными, и у разработчиков может возникнуть желание сохранить этот механизм выполнения действий в проектируемой системе. Тогда строится диаграмма деятельности для этих участков, отражающая конкретные особенности выполнения действий с использованием дорожек и объектов. В последующем такая диаграмма вкладывается в более общие диаграммы деятельности для подсистемы и системы в целом, сохраняя свой уровень детализации.

Таким образом, процесс объектно-ориентированного анализа и проектирования сложных систем представляется как последовательность итераций нисходящей и восходящей разработки отдельных диаграмм, включая и диаграмму деятельности. Доминирование того или иного из направлений разработки определяется особенностями конкретного проекта и его новизной.

В случае типового проекта большинство деталей реализации действий могут быть известны заранее на основе анализа существующих систем или предшествующего опыта разработки систем-прототипов. Для этой ситуации доминирующим будет восходящий процесс разработки (Зачем изобретать велосипед заново?). Использование типовых решений может существенно сократить время разработки и избежать возможных ошибок при реализации проекта.

При разработке проекта новой системы, процесс функционирования которой основан на новых технологических решениях, ситуация представляется более сложной. А именно, до начала работы над проектом могут быть неизвестны не только детали реализации отдельных деятельностей, но и само содержание этих деятельностей становится предметом разработки. В данном случае доминирующим будет нисходящий процесс разработки от более общих схем к уточняющим их диаграммам. При этом достижение такого уровня детализации всех диаграмм, который достаточен для понимания особенностей реализации всех действий и деятельностей, может служить признаком завершения отдельных этапов работы над проектом.

В заключение следует заметить, что диаграмма деятельности, так же как и другие виды канонических диаграмм, не содержит средств выбора оптимальных решений. При разработке сложных проектов проблема выбора оптимальных решений становится весьма актуальной. Рациональное расходование средств, затраченных на разработку и эксплуатацию системы, повышение ее производительности и надежности зачастую определяют конечный результат всего проекта. В такой ситуации можно рекомендовать использование дополнительных средств и методов, ориентированных на аналитико-имитационное исследование моделей системы на этапе разработки ее проекта.

В частности, при построении диаграмм деятельности сложных систем могут быть успешно использованы различные классы сетей Петри (классические, логико-алгебраические, стохастические, нечеткие и др.) и нейронных сетей. Применение этих формализмов позволяет не только получить оптимальную структуру поведения системы на ее модели, но и специфицировать целый ряд дополнительных характеристик системы, которые не могут быть представлены на диаграмме деятельности и других диаграммах UML.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 8
Диаграмма последовательности (sequence diagram)

  • 8.1. Объекты
    • Линия жизни объекта
    • Фокус управления
  • 8.2. Сообщения
    • Ветвление потока управления
    • Стереотипы сообщений
    • Временные ограничения на диаграммах последовательности
    • Комментарии или примечания
  • 8.3. Пример построения диаграммы последовательности
  • 8.4. Заключительные рекомендации по построению диаграмм последовательности

Как было отмечено в части I книги, одной из характерных особенностей систем различной природы и назначения является взаимодействие между собой отдельных элементов, из которых образованы эти системы. Речь идет о том, что различные составные элементы систем не существуют изолированно, а оказывают 'определенное влияние друг на друга, что и отличает систему как целостное образование от простой совокупности элементов.

В языке UML взаимодействие элементов рассматривается в информационном аспекте их коммуникации, т. е. взаимодействующие объекты обмениваются между собой некоторой информацией. При этом информация принимает форму законченных сообщений. Другими словами, хотя сообщение и имеет информационное содержание, оно приобретает дополнительное свойство оказывать направленное влияние на своего получателя. Это полностью согласуется с принципами ООАП, когда любые виды информационного взаимодействия между элементами системы должны быть сведены к отправке и приему сообщений между ними.

Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Говоря об этих диаграммах, имеют в виду два аспекта взаимодействия. Во-первых, взаимодействия объектов можно рассматривать во времени, и тогда для представления временных особенностей передачи и приема сообщений между объектами используется диаграмма последовательности. Этот вид канонических диаграмм является предметом изучения настоящей главы.

Ранее, при изучении диаграмм состояния и деятельности, было отмечено одно немаловажное обстоятельство. Хотя рассмотренные диаграммы и используются для спецификации динамики поведения систем, время в явном виде в них не присутствует. Однако временной аспект поведения может иметь существенное значение при моделировании синхронных процессов, описывающих взаимодействия объектов. Именно для этой цели в языке UML используются диаграммы последовательности.

Во-вторых, можно рассматривать структурные особенности взаимодействия объектов. Для представления структурных особенностей передачи и приема сообщений между объектами используется диаграмма кооперации. Этот вид канонических диаграмм является предметом изучения главы 9.

8.1. Объекты

На диаграмме последовательности изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии и не показываются возможные статические ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является именно динамика взаимодействия объектов во времени. При этом диаграмма последовательности имеет как бы два измерения. Одно — слева направо в виде вертикальных линий, каждая из которых изображает линию жизни отдельного объекта, участвующего во взаимодействии. Графически каждый объект изображается прямоугольником и располагается в верхней части своей линии жизни (рис. 8.1). Внутри прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся запись подчеркивается, что является признаком объекта, который, как известно, представляет собой экземпляр класса.

Примечание

Не исключается ситуация, когда имя объекта может отсутствовать на диаграмме последовательности. В этом случае указывается только имя класса, а сам объект считается анонимным.

Рис. 8.1. Различные графические примитивы диаграммы последовательности

Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 8.1). Правее изображается другой объект, который непосредственно взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом.

Второе измерение диаграммы последовательности — вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. При этом взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Другими словами, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".

Линия жизни объекта

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней (объекты 1 и 2 на рис. 8.1).

Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X" (объект 3 на рис. 8.1). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

Вовсе не обязательно создавать все объекты в начальный момент времени. Отдельные объекты в системе могут создаваться по мере необходимости, существенно экономя ресурсы системы и повышая ее производительность. В этом случае прямоугольник такого объекта изображается не в верхней части диаграммы последовательности, а в той ее части, которая соответствует моменту создания объекта (объект 6 на рис. 8.2). При этом прямоугольник объекта вертикально располагается в том месте диаграммы, которое по оси времени совпадает с моментом его возникновения в системе. Очевидно, объект обязательно создается со своей линией жизни и, возможно, с фокусом управления.

Рис. 8.2. Графическое изображение различных вариантов линий жизни и фокусов управления объектов

Фокус управления

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 8.1), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона — окончание фокуса управления (окончание активности). Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни (объект 4 на рис. 8.2), если на всем ее протяжении он является активным.

С другой стороны, периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления (объект 5 на рис. 8.2). Важно понимать, что получить фокус управления может только существующий объект, у которого в этот момент имеется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который, строго говоря, будет являться другим объектом.

В отдельных случаях инициатором взаимодействия в системе может быть актер или внешний пользователь. В этом случае актер изображается на диаграмме последовательности самым первым объектом слева со своим фокусом управления (рис. 8.3). Чаще всего актер и его фокус управления будут существовать в системе постоянно, отмечая характерную для пользователя активность в инициировании взаимодействий с системой. При этом сам актер может иметь собственное имя либо оставаться анонимным.

Иногда некоторый объект может инициировать рекурсивное взаимодействие с самим собой. Речь идет о том, что наличие во многих языках программирования специальных средств построения рекурсивных процедур требует визуализации соответствующих понятий в форме графических примитивов. На диаграмме последовательности рекурсия обозначается небольшим прямоугольником, присоединенным к правой стороне фокуса управления того объекта, для которого изображается это рекурсивное взаимодействие (объект 7 на рис. 8.3).

Рис. 8.3. Графическое изображение актера, рекурсии и рефлексивного сообщения на диаграмме последовательности

8.2. Сообщения

Как было отмечено выше, цель взаимодействия в контексте языка UML заключается в том, чтобы специфицировать коммуникацию между множеством взаимодействующих объектов. Каждое взаимодействие описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между собой. В этом смысле сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение определенных действий, направленных на решение отдельной задачи тем объектом, которому это сообщение отправлено.

Таким образом, сообщения не только передают некоторую информацию, но и требуют или предполагают от принимающего объекта выполнения ожидаемых действий. Сообщения могут инициировать выполнение операций объектом соответствующего класса, а параметры этих операций передаются вместе с сообщением. На диаграмме последовательности все сообщения упорядочены по времени своего возникновения в моделируемой системе.

В таком контексте каждое сообщение имеет направление от объекта, который инициирует и отправляет сообщение, к объекту, который его получает. Иногда отправителя сообщения называют клиентом, а получателя — сервером. При этом сообщение от клиента имеет форму запроса некоторого сервиса, а реакция сервера на запрос после получения сообщения может быть связана с выполнением определенных действий или передачи клиенту необходимой информации тоже в форме сообщения.

Рис. 8.4. Графическое изображение различных видов сообщений между объектами на диаграмме последовательности

В языке UML могут встречаться несколько разновидностей сообщений, каждое из которых имеет свое графическое изображение (рис. 8.4).

  • Первая разновидность сообщения (рис. 8.4, а) является наиболее распространенной и используется для вызова процедур, выполнения операций или обозначения отдельных вложенных потоков управления. Начало этой стрелки всегда соприкасается с фокусом управления или линией жизни того объекта-клиента, который инициирует это сообщение. Конец стрелки соприкасается с линией жизни того объекта, который принимает это сообщение и выполняет в ответ определенные действия. При этом принимающий объект зачастую получает и фокус управления, становясь активным.
  • Вторая разновидность сообщения (рис. 8.4, б) используется для обозначения простого (не вложенного) потока управления. Каждая такая стрелка указывает на прогресс одного шага потока. При этом соответствующие сообщения обычно являются асинхронными, т. е. могут возникать в произвольные моменты времени. Передача такого сообщения обычно сопровождается получением фокуса управления объектом, его принявшим.
  • Третья разновидность (рис. 8.4, в) явно обозначает асинхронное сообщение между двумя объектами в некоторой процедурной последовательности. Примером такого сообщения может служить прерывание операции при возникновении исключительной ситуации. В этом случае информация о такой ситуации передается вызывающему объекту для продолжения процесса дальнейшего взаимодействия.
  • Наконец, последняя разновидность сообщения (рис. 8.4, г) используется для возврата из вызова процедуры. Примером может служить простое сообщение о завершении некоторых вычислений без предоставления результата расчетов объекту-клиенту. В процедурных потоках управления эта стрелка может быть опущена, поскольку ее наличие неявно предполагается в конце активизации объекта. В то же время считается, что каждый вызов процедуры имеет свою пару — возврат вызова. Для непроцедурных потоков управления, включая параллельные и асинхронные сообщения, стрелка возврата должна указываться явным образом.

Обычно сообщения изображаются горизонтальными стрелками, соединяющими линии жизни или фокусы управления двух объектов на диаграмме последовательности. При этом неявно предполагается, что время передачи сообщения достаточно мало по сравнению с процессами выполнения действий объектами. Считается также, что за время передачи сообщения с соответствующими объектами не может произойти никаких событий. Другими словами, состояния объектов остаются без изменения. Если же это предположение не может быть признано справедливым, то стрелка сообщения изображается под некоторым наклоном, так чтобы конец стрелки располагался ниже ее начала.

В отдельных случаях объект может посылать сообщения самому себе, инициируя так называемые рефлексивные сообщения (объект 8 на рис. 8.3). Такие сообщения изображаются прямоугольником со стрелкой, начало и конец которой совпадают. Подобные ситуации возникают, например, при обработке нажатий на клавиши клавиатуры при вводе текста в редактируемый документ, при наборе цифр номера телефона абонента.

Таким образом, в языке UML каждое сообщение ассоциируется с некоторым действием, которое должно быть выполнено принявшим его объектом. При этом действие может иметь некоторые аргументы или параметры, в зависимости от конкретных значений которых может быть получен различный результат. Соответствующие параметры будет иметь и вызывающее это действие сообщение. Более того, значения параметров отдельных сообщений могут содержать условные выражения, образуя ветвление или альтернативные пути основного потока управления.

Ветвление потока управления

Для изображения ветвления рисуются две или более стрелки, выходящие из одной точки фокуса управления объекта (фокус управления объекта 1 на рис. 8.5). При этом соответствующие условия должны быть явно указаны рядом с каждой из стрелок в форме сторожевого условия. Как нетрудно представить, если условие записано в форме булевского выражения, то ветвление будет содержать только две ветви. В любом случае условия должны взаимно исключать одновременную передачу альтернативных сообщений.

С помощью ветвления можно изобразить и более сложную логику взаимодействия объектов между собой (фокус управления объекта 1 на рис. 8.6). Если условий более двух, то для каждого из них необходимо предусмотреть ситуацию единственного выполнения. Рассматриваемый пример относится к моделированию взаимодействия программной системы обслуживания клиентов в банке. На этом примере диаграммы последовательности объект 1 передает управление одному из трех других объектов.

Рис. 8.5. Графическое изображение бинарного ветвления потока управления на диаграмме последовательности

Рис. 8.6. Графическое изображение тернарного ветвления потока управления на диаграмме последовательности

Условием ветвления может служить сумма снимаемых клиентом средств со своего текущего счета. Если эта сумма превышает $1000, то могут потребоваться дополнительные действия, связанные с созданием и последующим разрушением объекта 4. Если же сумма превышает $50, но не превышает $1000, то управление передается объекту 3. И, наконец, если сумма не превышает $50, то управление получает объект 2. При этом объекты 1, 2 и 3 постоянно существуют в системе. Объект 4 создается, только если справедливо первое из альтернативных условий. В противном случае он может быть никогда не создан. После выполнения требуемых действий объекты 2 и 3 просто информируют объект 1 о завершении соответствующих операций, не требуя от него никаких действий (пунктирная стрелка). Объект 4 после завершения своих действий уничтожается, передавая управление объекту 3, делая его активным (фокус управления).

Стереотипы сообщений

В языке UML предусмотрены некоторые стандартные действия, выполняемые в ответ на получение соответствующего сообщения. Они могут быть явно указаны на диаграмме последовательности в форме стереотипа рядом с сообщением, к которому они относятся. В этом случае они записываются в кавычках. Используются следующие обозначения для моделирования действий:

  • "call" (вызвать) — сообщение, требующее вызова операции или процедуры принимающего объекта. Если сообщение с этим стереотипом рефлексивное, то оно инициирует локальный вызов операции у самого пославшего это сообщение объекта;
  • "return" (возвратить) — сообщение, возвращающее значение выполненной операции или процедуры вызвавшему ее объекту. Значение результата может инициировать ветвление потока управления;
  • "create" (создать) — сообщение, требующее создания другого объекта для выполнения определенных действий. Созданный объект может получить фокус управления, а может и не получить его;
  • "destroy" (уничтожить) — сообщение с явным требованием уничтожить соответствующий объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны существующего в системе объекта, либо когда объект больше не нужен и должен освободить задействованные им системные ресурсы;
  • "send" (послать) — обозначает посылку другому объекту некоторого сигнала, который асинхронно инициируется одним объектом и принимается (перехватывается) другим. Отличие сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект которого инициирует его передачу.

Ниже представлена диаграмма последовательности для рассмотренного выше случая ветвления, дополненная стереотипными значениями (рис. 8.7).

Кроме стереотипов, сообщения могут иметь собственное обозначение операции, вызов которой они инициируют у принимающего объекта. В этом случае рядом со стрелкой записывается имя операции с круглыми скобками, в которых могут указываться параметры или аргументы соответствующей операции. Если параметры отсутствуют, то скобки все равно должны присутствовать после имени операции. Примерами таких операций могут служить следующие: "выдать клиенту наличными сумму (п)", "установить соединение между абонентами (а, Ь)", "сделать вводимый текст невидимым ()", "подать звуковой сигнал тревоги ()".

Примечание

Согласно принятой в языке UML системе обозначений такие имена операций записываются на английском с малой буквы и одним словом, возможно, состоящим из нескольких сокращенных слов, написанных без пробела и без кавычек. Если нет никаких дополнительных ограничений со стороны инструментальных средств визуализации канонических диаграмм, то дело вкуса отечественного разработчика, какие обозначения ему использовать в русскоязычной транслитерации. Возможно, для этой цели больше подходит вариант с нижней черточкой, исключающей пробелы в имени операции: "сделать_вводимый_текст_ невидимым()", чем вариант с заглавными буквами в середине имени операции: "сделатьВводимыйТекстНевидимым()".

Рис. 8.7. Диаграмма последовательности со стереотипными значениями сообщений

Временные ограничения на диаграммах последовательности

В отдельных случаях выполнение тех или иных действий на диаграмме последовательности может потребовать явной спецификации временных ограничений, накладываемых на сам интервал выполнения операций или передачу сообщений. В языке UML для записи временных ограничений используются фигурные скобки. Временные ограничения могут относиться как к выполнению определенных действий объектами, так и к самим сообщениям, явно специфицируя условия их передачи или приема. Важно понимать, что в отличие от условий ветвления, которые должны выполняться альтернативно, временные ограничения имеют обязательный или директивный характер для ассоциированных с ними объектов.

Временные ограничения могут записываться рядом с началом стрелки соответствующего сообщения. Но наиболее часто они записываются слева от этой стрелки на одном уровне с ней. Если временная характеристика относится к конкретному объекту, то имя этого объекта записывается перед именем характеристики и отделяется от нее точкой.

Примерами таких ограничений на диаграмме последовательности могут служить ситуации, когда необходимо явно специфицировать время, в течение которого допускается передача сообщения от клиента к серверу или обработка запроса клиента сервером:

  • {время_приема_сообщения время_отправки_сообщения < 1 сек.}
  • {время_ожидания_ответа < 5 сек.}
  • {время_передачи_пакета < 10 сек.}
  • {объект_1. время_подачи_сигнала_тревоги > 30 сек.}

Примечание

В первом из рассмотренных случаев знак "-" во временном ограничении обозначает арифметическую операцию вычитания (минус). Другие знаки являются обычными знаками сравнения величин. В последнем случае перед временной характеристикой указано имя объекта, к которому она относится.

Комментарии или примечания

Комментарии или примечания уже рассматривались ранее при изучении других видов диаграмм. Они могут включаться и в диаграммы последовательности, ассоциируясь с отдельными объектами или сообщениями. При этом используется стандартное обозначение для комментария — прямоугольник с "заломленным" правым верхним углом. Внутри этого прямоугольника записывается текст комментария на естественном языке.

8.3. Пример построения диаграммы последовательности

В качестве примера рассмотрим построение диаграммы последовательности для моделирования процесса телефонного разговора с использованием обычной телефонной сети. Объектами в этом примере являются: два абонента а и Ь, два телефонных аппарата end, коммутатор и сам разговор как объект моделирования. При этом как коммутатор, так и разговор являются анонимными объектами.

На первом этапе располагаем выбранные объекты на предполагаемой диаграмме (рис. 8.8). Заметим, что абонентов мы будем рассматривать как актеров, причем первый из них — а — играет активную роль, а второй — b — пассивную роль. Поэтому первый получает фокус управления сразу после своего появления в системе, а второй имеет только линию жизни. Коммутатор также имеет постоянную активность, что изображается его фокусом управления. Разговор как объект появляется только после установки соединения и уничтожается с его прекращением. Поэтому он будет изображен позже на этой же диаграмме последовательности.

Рис. 8.8. Начальный фрагмент диаграммы последовательности для моделирования телефонного разговора

Процесс взаимодействия в этой системе начинается с поднятия трубки телефонного аппарата первым абонентом. Тем самым он посылает сообщение телефонному аппарату с, которое переводит этот аппарат в активное состояние и вызывает действие — подачу тонового сигнала в телефонную трубку для первого абонента. Следующее действие также инициируется первым абонентом — набор цифр телефонного номера. Это представлено в форме итеративного сообщения со знаком "*" слева от его имени.

Заметим, что поднятие телефонной трубки и набор цифр номера являются физическими действиями и поэтому изображаются в форме простых асинхронных сообщений. После набора цифр'номера телефона аппарат с рекурсивно вызывает процедуру посылки коммутационных импульсов на коммутатор. Последний инициирует создание нового объекта в моделируемой системе — телефонного разговора. Дополненный фрагмент диаграммы последовательности изображен на рис. 8.9.

После создания анонимный объект "разговор" сразу получает фокус активности и посылает сообщение телефонному аппарату d на выполнение действия — звонка вызова. При этом второй абонент снимает трубку (асинхронное сообщение), тем самым устанавливается прямое соединение между абонентами а и Ь. После того как абоненты опустят трубки, разговор заканчивается. Тем самым объект "разговор" уничтожается. Окончательный вариант диаграммы последовательности может содержать некоторые временные ограничения и комментарии (рис. 8.10). Назначение отдельных сообщений соответствуют рассмотренным действиям.

Рис. 8.9. Дополненный фрагмент диаграммы последовательности для моделирования телефонного разговора

Рис. 8.10. Окончательный вариант диаграммы последовательности для моделирования телефонного разговора

Примечание

Дополнить диаграмму последовательности для этого примера временными ограничениями предлагается выполнить самостоятельно в качестве упражнения.

8.4. Заключительные рекомендации по построению диаграмм последовательности

Как уже отмечалось, построение диаграммы последовательности целесообразно начинать с выделения из всей совокупности тех и только тех классов, объекты которых участвуют в моделируемом взаимодействии. После этого все объекты наносятся на диаграмму с соблюдением некоторого порядка инициализации сообщений. Здесь необходимо установить, какие объекты будут существовать постоянно, а какие временно — только на период выполнения ими требуемых действий.

Когда объекты визуализированы, можно приступать к спецификации сообщений. При этом следует учитывать те роли, которые играют сообщения в системе. При необходимости уточнения этих ролей надо использовать их разновидности и стереотипы. Для уничтожения объектов, которые создаются на время выполнения своих действий, нужно предусмотреть явное сообщение.

Наиболее простые случаи ветвления процесса взаимодействия можно изобразить на одной диаграмме с использованием соответствующих графических примитивов. Однако следует помнить, что каждый альтернативный поток управления может существенно затруднить понимание построенной модели. Поэтому общим правилом является визуализация каждого потока управления на отдельной диаграмме последовательности. В этой ситуации такие отдельные диаграммы должны рассматриваться совместно как одна модель взаимодействия.

Дальнейшая детализация диаграммы последовательности связана с введением временных ограничений на выполнение отдельных действий в системе. Для простых асинхронных сообщений временные ограничения могут отсутствовать. Однако необходимость синхронизировать сложные потоки управления, как правило, требуют введение в модель таких ограничений. Общая их запись должна следовать семантике языка объектных ограничений, который рассмотрен в приложении.

На главную страницу


Леоненков. Самоучитель UML.

Оглавление

ГЛАВА 9
Диаграмма кооперации (collaboration diagram)

  • 9.1. Кооперация
    • Диаграмма кооперации уровня спецификации
  • 9.2. Объекты
    • Мультиобъект
    • Активный объект
    • Составной объект
  • 9.3. Связи
    • Стереотипы связей
  • 9.4. Сообщения
    • Формат записи сообщений
  • 9.5. Пример построения диаграммы кооперации
  • 9.6. Заключительные рекомендации по построению диаграмм кооперации

Как отмечалось в предыдущей главе, особенности взаимодействия элементов моделируемой системы могут быть представлены на диаграммах последовательности и кооперации. Если первая служит для визуализации временных аспектов взаимодействия, то диаграмма кооперации предназначена для спецификации структурных аспектов взаимодействия. Главная особенность диаграммы кооперации заключается в возможности графически представить не только последовательность взаимодействия, но и все структурные отношения между объектами, участвующими в этом взаимодействии.

Прежде всего, на диаграмме кооперации в виде прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта, его класс и, возможно, значения атрибутов. Далее, как и на диаграмме классов, указываются ассоциации между объектами в виде различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи — потоки сообщений. Они представляются также в виде соединительных линий между объектами, над которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в общей последовательности инициализации сообщений.

В отличие от диаграммы последовательности, на диаграмме кооперации изображаются только отношения между объектами, играющими определенные роли во взаимодействии. С другой стороны, на этой диаграмме не указывается время в виде отдельного измерения. Поэтому последовательность взаимодействий и параллельных потоков может быть определена с помощью порядковых номеров. Следовательно, если необходимо явно специфицировать взаимосвязи между объектами в реальном времени, лучше это делать на диаграмме последовательности.

Поведение системы может описываться на уровне отдельных объектов, которые обмениваются между собой сообщениями, чтобы достичь нужной цели или реализовать некоторый сервис. С точки зрения аналитика или конструктора важно представить в проекте системы структурные связи отдельных объектов между собой. Такое статическое представление структуры системы как совокупности взаимодействующих объектов и обеспечивает диаграмма кооперации.

Таким образом, с помощью диаграммы кооперации можно описать полный контекст взаимодействий как своеобразный временной "среза" совокупности объектов, взаимодействующих между собой для выполнения определенной задачи или бизнес-цели программной системы.

9.1. Кооперация

Понятие кооперации (collaboration) является одним из фундаментальных понятий в языке UML. Оно служит для обозначения множества взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Цель самой кооперации состоит в том, чтобы специфицировать особенности реализации отдельных наиболее значимых операций в системе. Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой кооперации.

Кооперация может быть представлена на двух уровнях:

  • На уровне спецификации — показывает роли классификаторов и роли ассоциаций в рассматриваемом взаимодействии.
  • На уровне примеров — указывает экземпляры и связи, образующие отдельные роли в кооперации.

Диаграмма кооперации уровня спецификации показывает роли, которые играют участвующие во взаимодействии элементы. Элементами кооперации на этом уровне являются классы и ассоциации, которые обозначают отдельные роли классификаторов и ассоциации между участниками кооперации.

Диаграмма кооперации уровня примеров представляется совокупностью объектов (экземпляры классов) и связей (экземпляры ассоциаций). При этом связи дополняются стрелками сообщений. На данном уровне показываются только релевантные объекты, т. е. имеющие непосредственное отношение к реализации операции или классификатора.

В кооперации уровня примеров определяются свойства, которые должны иметь экземпляры для того, чтобы участвовать в кооперации. Кроме свойств объектов на диаграмме кооперации также указываются ассоциации, которые должны иметь место между объектами кооперации. При этом вовсе не обязательно изображать все свойства или все ассоциации, поскольку на диаграмме кооперации присутствуют только роли классификаторов, но не сами классификаторы. Таким образом, в то время как классификатор требует полного описания всех своих экземпляров, роль классификатора требует описания только тех свойств и ассоциаций, которые необходимы для участия в отдельной кооперации.

Отсюда вытекает важное следствие. Одна и та же совокупность объектов может участвовать в различных кооперациях. При этом, в зависимости от рассматриваемой кооперации, могут изменяться как свойства отдельных объектов, так и связи между ними. Именно это отличает диаграмму кооперации от диаграммы классов, на которой должны быть указаны все свойства и ассоциации между элементами диаграммы.

Диаграмма кооперации уровня спецификации

Кооперация на уровне спецификации изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации (рис. 9.1). Такое представление кооперации относится к отдельному варианту использования и детализирует особенности его последующей реализации. Символ эллипса кооперации соединяется отрезками пунктирной линии с каждым из участников этой кооперации, в качестве которых могут выступать объекты или классы. Каждая из этих пунктирных линий помечается ролью (role) участника. Роли соответствуют именам элементов в контексте всей кооперации. Эти имена трактуются как параметры, которые ограничивают спецификацию элементов при любом их появлении в отдельных представлениях модели.

Рис. 9.1. Общее представление кооперации на диаграммах уровня спецификации

Простой класс на диаграмме кооперации обозначается прямоугольником класса, внутри которого записывается строка текста. Эта строка текста называется ролью классификатора (classifier role). Роль классификатора показывает особенность использования объектов данного класса. Обычно в прямоугольнике показывается только секция имени класса, хотя не исключается возможность указания секций атрибутов и операций.

Строка текста в прямоугольнике должна иметь следующий формат:

'/' <Имя роли классификатора> ':' <Имя классификатора>

[':' <Имя классификатора >]*

Здесь Имя классификатора, если это необходимо, может включать полный путь всех вложенных пакетов. При этом один пакет от другого отделяется двойным двоеточием "::". Если не возникает путаницы, можно ограничиться указанием только ближайшего из пакетов, которому принадлежит данная кооперация. Символ "*" применяется для указания возможности итеративного повторения имени классификатора.

Если кооперация допускает обобщенное представление, то на диаграммах могут быть указаны отношения обобщения соответствующих элементов. Этот способ может быть использован для определения отдельных коопераций, которые являются, в свою очередь, частным случаем или специализацией другой кооперации. Такая ситуация изображается обычной стрелкой обобщения, направленной от символа дочерней кооперации к символу кооперации-предка (рис. 9.2). При этом роли дочерних коопераций могут быть специализациями ролей коопераций-предков.

Рис. 9.2. Графическое изображение отношения обобщения между отдельными кооперациями уровня спецификации

В отдельных случаях возникает необходимость явно указать тот факт, что кооперация является реализацией некоторой операции или классификатора. Это можно представить одним из двух способов.

Во-первых, можно соединить символ кооперации пунктирной линией со стрелкой обобщения с символом класса, реализацию операции которого специфицирует данная кооперация (рис. 9.3, а). Так, если в качестве класса рассмотреть "Заказ на покупку товара", у которого имеется операция "оформить_заказ (), то ее реализация может быть специфицирована в форме кооперации.

Рис. 9.3. Способы представления кооперации, которая реализует операцию класса

Во-вторых, можно просто изобразить символ кооперации, внутри которого указать всю необходимую информацию, записанную по определенным правилам (рис. 9.3, б). Эти правила определяют формат записи имени кооперации, после которого записывают двоеточие и имя класса. За именем класса следует двойное двоеточие и имя операции.

Подобное общее представление кооперации на уровне спецификации используется на начальных этапах проектирования. В последующем каждая из коопераций подлежит детализации на уровне примеров, на котором раскрывается содержание и структура взаимосвязей ее элементов на отдельной диаграмме кооперации. При этом в качестве элементов диаграммы кооперации выступают объекты и связи, дополненные сообщениями. Именно эти элементы являются предметом дальнейшего рассмотрения в настоящей главе.

9.2. Объекты

Отдельные аспекты спецификации объектов как элементов диаграмм уже рассматривались ранее при описании диаграмм классов (см. главу 5) и последовательности (см. главу 8). Сейчас мы более подробно остановимся на особенностях их семантики и графической нотации, поскольку объекты являются основными элементами или графическими примитивами, из которых строится диаграмма кооперации на уровне примеров. Для графического изображения объектов используется такой же символ прямоугольника, что и для классов.

Как отмечалось выше, объект (object) является отдельным экземпляром класса, который создается на этапе выполнения программы. Он может иметь свое собственное имя и конкретные значения атрибутов. Применительно к объектам формат строки классификатора дополняется именем объекта и приобретает следующий вид (при этом вся запись подчеркивается):

<Имя объекта>'/' <Имя роли классификатора> ':' <Имя классификатора>

[':' <Имя классификатора >]*

Здесь Имя роли классификатора может не указываться. В этом случае оно исключается из строки текста вместе с последующим двоеточием. Имя роли может быть опущено в том случае, если существует только одна роль в кооперации, которую могут играть объекты, созданные на базе этого класса.

Таким образом, для обозначения роли классификатора достаточно указать либо имя класса (вместе с двоеточием), либо имя роли (вместе с наклонной чертой). В противном случае прямоугольник будет соответствовать обычному классу. Если роль, которую должен играть объект, наследуется от нескольких классов, то все они должны быть указаны явно и разделяться запятой и двоеточием.

Примечание

В прямоугольнике объекта имя объекта, имя роли с символом Т или имя класса могут отсутствовать. Однако двоеточие всегда должно стоять перед именем класса, а косая черточка — перед именем роли. Следует еще раз акцентировать внимание на том обстоятельстве, что применительно к объектам вся запись должна быть подчеркнута, а имя объекта должно быть записано со строчной буквы.

Ниже приводятся возможные варианты записи строки текста в прямоугольнике объекта.

  • : С — анонимный объект, образуемый на основе класса С.
  • / R — анонимный объект, играющий роль R.
  • / R : С — анонимный объект, образуемый на основе класса С и играющий роль R.
  • О / R — объект с именем О, играющий роль R.
  • О : С — объект с именем О, образуемый на основе класса С.
  • О / R : С — объект с именем О, образуемый на основе класса С и играющий роль R.
  • О или — объект с именем О.
  • О : — "объект-сирота" с именем О.
  • / R — роль с именем R
  • : С — анонимная роль на базе класса С.
  • / R : С — роль с именем R на основе класса С.

Отдельные примеры изображения объектов и классов на диаграмме кооперации приводятся на следующем рисунке (рис. 9.4).

Рис. 9.4. Примеры различных вариантов записи имен объектов, ролей и классов на диаграммах кооперации

Так, в первом случае (рис. 9.4, а) обозначен объект с именем "клиент", играющий роль "инициатор запроса". Далее (рис. 9.4, б) следует обозначение анонимного объекта, который играет роль инициатора запроса. В обоих случаях не указан класс, на основе которого будут созданы эти объекты. Обозначение класса присутствует в следующем варианте записи (рис. 9.4, в), причем объект также анонимный.

Применительно к уровню спецификации на диаграммах кооперации могут присутствовать именованные классы с указанием роли класса в кооперации (рис. 9.4, г) или анонимные классы, когда указывается только его роль (рис. 9.4, д). Последний случай характерен для ситуации, когда в модели могут присутствовать несколько классов с именем "Клиент", поэтому требуется явно указать имя соответствующего пакета База данных (рис. 9.4, е).

Мультиобъект

Мультиобъект (multiobject) представляет собой целое множество объектов на одном из концов ассоциации. На диаграмме кооперации Мультиобъект используется для того, чтобы показать операции и сигналы, которые адресованы всему множеству объектов, а не только одному. Мультиобъект изображается двумя прямоугольниками, один из которых выступает из-за верхней правой вершины другого (рис. 9.5, а). При этом стрелка сообщения относится ко всему множеству объектов, которые обозначают данный мульти-объект. На диаграмме кооперации может быть явно указано отношение композиции между мультиобъектом и отдельным объектом из его множества (рис. 9.5, б).

Рис. 9.5. Графическое изображение мультиобъектов на диаграмме кооперации

Активный объект

В контексте языка UML все объекты делятся на две категории: пассивные и активные. Пассивный объект оперирует только данными и не может инициировать деятельность по управлению другими объектами. Однако пассивные объекты могут посылать сигналы в процессе выполнения запросов, которые они получают.

Активный объект (active object) имеет свою собственную нить (thread) управления и может инициировать деятельность по управлению другими объектами. При этом под нитью понимается некоторый облегченный поток управления, который может выполняться параллельно с другими вычислительными нитями или нитями управления в пределах одного вычислительного процесса или процесса управления.

Примечание

Отличие между процессом и нитью заключается в степени использования ресурсов. Говоря о процессе, имеют в виду ресурсоемкий поток управления, т. е. процесс полностью монополизирует ресурсы системы. Нить может использовать лишь небольшую часть ресурсов системы. Примером может служить выполнение некоторой программы в своем адресном пространстве или в фоновом режиме.

Активные объекты на канонических диаграммах обозначаются прямоугольником с более широкими границами (рис. 9.6). Иногда может быть явно указано ключевое слово (помеченное значение) {active}, чтобы выделить активный объект на диаграмме. Каждый активный объект может инициировать единственную нить или процесс управления и представлять исходную точку потока управления. В приведенном фрагменте диаграммы кооперации активный объект "а: Вызывающий абонент" является инициатором процесса установления соединения для обмена информацией с другим абонентом (на диаграмме не показан).

Рис. 9.6. Графическое изображение активного объекта (слева) на диаграмме кооперации

В следующем примере рассматривается ситуация с вызовом функции печати из текстового редактора (рис. 9.7). Анонимный активный объект "Текстовый редактор" вначале посылает сообщение анонимному мультиобъекту "Принтер", которое инициирует выбор единственного объекта "Принтер", возможно, удовлетворяющего некоторым дополнительным условиям. После этого выбранному объекту посылается сообщение о необходимости напечатать документ, загруженный в текстовый редактор.

Рис. 9.7. Фрагмент диаграммы кооперации для вызова функции печати из текстового редактора

Составной объект

Составной объект (composite object) или объект-контейнер предназначен для представления объекта, имеющего собственную структуру и внутренние потоки (нити) управления. Составной объект является экземпляром составного класса (класса-контейнера), который связан отношением агрегации или композиции (см. главу 5) со своими частями. Аналогичные отношения связывают между собой и соответствующие объекты.

На диаграммах кооперации такой составной объект изображается как обычный объект, состоящий из двух секций: верхней и нижней. В верхней секции записывается имя составного объекта, а в нижней — его составные части вместо списка его атрибутов (рис. 9.8). При этом допускается иметь в качестве частей другие составные объекты.

Рис. 9.8. Графическое изображение составного объекта на диаграмме кооперации

9.3. Связи

Связь (link) является экземпляром или примером произвольной ассоциации. Связь как элемент языка UML может иметь место между двумя и более объектами. Бинарная связь на диаграмме кооперации изображается отрезком прямой линии, соединяющей два прямоугольника объектов (см. рис. 9.7). На каждом из концов этой линии могут быть явно указаны имена ролей данной ассоциации. Рядом с линией в ее средней части может записываться имя соответствующей ассоциации.

Связи не имеют собственных имен, поскольку полностью идентичны как экземпляры ассоциации. Другими словами, все связи на диаграмме кооперации могут быть только анонимными и записываются без двоеточия перед-именем ассоциации. Для связей не указывается также и кратность. Однако другие обозначения специальных случаев ассоциации (агрегация, композиция) могут присутствовать на отдельных концах связей. Например, символ связи типа "композиция" между мультиобъектом "Принтер" и отдельным объектом "Принтер" (см. рис. 9.7).

Стереотипы связей

Связь может иметь некоторые стереотипы, которые записываются рядом с одним из ее концов и указывают на особенность реализации данной связи. В языке UML для этой цели могут использоваться следующие стереотипы:

  • "association" — ассоциация (предполагается по умолчанию, поэтому этот стереотип можно не указывать).
  • "parameter" — параметр метода. Соответствующий объект может бытьч только параметром некоторого метода.
  • "local" — локальная переменная метода. Ее область видимости ограничена только соседним объектом.
  • "global" — глобальная переменная. Ее область видимости распространяется на всю диаграмму кооперации.
  • "self — рефлексивная связь объекта с самим собой, которая допускает передачу объектом сообщения самому себе. На диаграмме кооперации рефлексивная связь изображается петлей в верхней части прямоугольника объекта.

Некоторые примеры связей с различными стереотипами изображены на рис. 9.9. Здесь представлена обобщенная схема некоторой конкретной компании с именем "С", которая состоит из отделов (анонимный мультиобъект "Отдел"). Последние, в свою очередь, состоят из сотрудников (анонимный мультиобъект "Сотрудник"). Рефлексивная связь указывает на тот факт, что менеджер отдела является в то же время и его сотрудником.

Рис. 9.9. Графическое изображение связей с различными стереотипами

Примечание

Поскольку на данной диаграмме отсутствуют сообщения, то она не является, строго говоря, диаграммой кооперации. Скорее это специальный случай диаграммы классов, который иногда называют диаграммой объектов. В случае N-арной связи эта связь изображается аналогично N-арной ассоциации с использованием символа ромба.

9.4. Сообщения

Сообщения, как элементы языка LJML, уже рассматривались ранее при изучении диаграммы последовательности (см. главу 8). При построении диаграммы кооперации они имеют некоторые дополнительные семантические особенности. Сообщение на диаграмме кооперации специфицирует коммуникацию между двумя объектами, один из которых передает другому некоторую информацию. При этом первый объект ожидает, что после получения сообщения вторым объектом последует выполнение некоторого действия. Таким образом, именно сообщение является причиной или стимулом для начала выполнения операций, отправки сигналов, создания и уничтожения отдельных объектов. Связь обеспечивает канал для направленной передачи сообщений между объектами от объекта-источника к объекту-получателю.

Рис. 9.10. Графическое изображение различных типов сообщений на диаграмме кооперации

Сообщения в языке UML также специфицируют роли, которые играют объекты — отправитель и получатель сообщения. Сообщения на диаграмме кооперации изображаются помеченными стрелками рядом (выше или ниже) с соответствующей связью или ролью ассоциации. Направление стрелки указывает на получателя сообщения. Внешний вид стрелки сообщения имеет определенный смысл. На диаграммах кооперации может использоваться один из четырех типов стрелок для обозначения сообщений (рис. 9.10):

  1. Сплошная линия с треугольной стрелкой (рис. 9.10, а) обозначает вызов процедуры или другого вложенного потока управления. Может быть также использована совместно с параллельно активными объектами, когда один из них передает сигнал и ожидает, пока не закончится некоторая вложенная последовательность действий. Обычно все такие сообщения являются синхронными, т. е. инициируемыми по завершении некоторой деятельности или при выполнении некоторого условия.
  2. Сплошная линия с V-образной стрелкой (рис. 9.10, б) обозначает простой поток управления. Каждая такая стрелка изображает один этап в последовательности потока управления. Обычно все такие сообщения являются асинхронными.
  3. Сплошная линия с полустрелкой (рис. 9.10, в) используется для обозначения асинхронного потока управления. Соответствующие сообщения формируются в произвольные, заранее не известные моменты времени, как правило, активными объектами. Обычно сообщения этого типа являются начальными в последовательности потока управления и чаще всего инициируются актерами.
  4. Пунктирная линия с V-образной стрелкой (рис. 9.10, г) обозначает возврат из вызова процедуры. Стрелки этого типа зачастую отсутствуют на диаграммах кооперации, поскольку неявно предполагается их существование после окончания процесса активизации некоторой деятельности.

Формат записи сообщений

Каждое сообщение может быть помечено строкой текста, которая имеет следующий формат:

< Предшествующие сообщения> < [Сторожевое условие] >

<Выражение последовательности>

<Возвращаемое значение— имя сообщения> <Список аргументов>

Рассмотрим каждый из этих элементов более подробно.

  • Предшествующие сообщения — есть разделенные запятыми номера сообщений, записанные перед наклонной черточкой:

<Номер сообщения ','>< Номер сообщения,'> '/'

Если список номеров сообщений пуст, то вся запись, включая наклонную черточку (слэш), опускается. Каждый номер сообщения может быть выражением последовательности без рекурсивных символов. Выражение должно определять номер другого сообщения в этой же последовательности.

Примечание

Заметим, что сами номера последовательности сообщений с одинаковым префиксом образуют отношение упорядоченности и, соответственно, неявно указывают на предшествующие сообщения. Таким предшествующим сообщением будет сообщение с номером, самая правая цифра которого на единицу меньше, чем у рассматриваемого сообщения. Например, сообщение с номером "3.1.4.6" имеет в качестве предшествующего сообщение с номером "3.1.4.5".

Смысл указания предшествующих сообщений заключается в том, что данное сообщение не может быть передано, пока не будут переданы своим адресатам все сообщения, номера которых записаны в данном списке.

Пример записи предшествующих сообщений:

A3, В4/ С5: ошибка записи (сектор).

  • Сторожевое условие является обычным булевским выражением и предназначено для синхронизации отдельных нитей потока управления. Записывается в квадратных скобках и может быть опущено, если оно отсутствует у данного сообщения. Семантика сторожевого условия обеспечивает передачу сообщения только в том случае, если это условие принимает значение "истина".

Пример записи сторожевых условий без номеров предшествующих сообщений:

  • [(х>=0)&(х<=255)] 1.2: отобразить_на_экране_цвет(х)
  • [количество цифр номера = 7] 3.1: набрать_телефонный_номер()
  • Выражение последовательности — есть разделенный точками список отдельных термов последовательностей, после которого записывается двоеточие:

<Терм последовательности'.'><Терм последовательности'.'>':'

Каждый из термов представляет отдельный уровень процедурной вложенности в форме законченной итерации. Наиболее верхний уровень соответствует самому левому терму последовательности. Если все потоки управления параллельные, то вложенность отсутствует. Каждый из термов последовательности имеет следующий синтаксис:

[Целое число| Имя] [Символ рекуррентности].

  • Целое число указывает на порядковый номер сообщения в процедурной последовательности верхнего уровня. Сообщения, номера которых отличаются на единицу, следуют подряд один за другим.

Например, сообщение с номером "3.1.4" следует за сообщением с номером "3.1.3" в процедурной последовательности "3.1".

  • Имя используется для спецификации параллельных нитей управления. Сообщения, которые отличаются только именем, являются параллельными на этом уровне вложенности. На одном уровне вложенности все нити управления эквивалентны в смысле приоритета передачи сообщений. С

Например, сообщения с выражениями "ЗЛа" и "3.16" являются параллельными в процедурной последовательности "3.1".

  • Символ рекуррентности используется для указания условного или итеративного выполнения. Семантика рекуррентности представляет ноль или больше сообщений, которые должны быть выполнены в зависимости от записанного условия. Возможны два случая записи рекуррентности:
  1. '*' '[' Предложение-итерация ']' для записи итеративного выполнения соответствующего выражения.

Итерация представляет последовательность сообщений одного уровня вложенности. Предложение-итерация может быть опущено, если условия итерации никак не специфицируются. Наиболее часто предложение-итерация записывается на некотором псевдокоде или языке программирования. В языке UML формат записи этого предложения не определен. Например, "*[/:=/..л]", что означает последовательную передачу сообщения с параметром /, который изменяется от 1 до некоторого целого числа п с шагом 1.

  2. '['Предложение-условие У для записи ветвления. Это условие представляет такое сообщение, передача которого по данной ветви возможна только при истинности этого условия. Чаще всего предложение-условие записывают на некотором псевдокоде или языке программирования, поскольку в языке UML формат записи этого предложения не определен. Например, [х>у] означает, что сообщение по некоторой ветви будет передано только в том случае, если значение х больше значения у.

Примечание

Заметим, что условие записывается так же, как и итерация, но без звездочки. Это можно понимать как некоторую одношаговую итерацию. При этом предполагается, что итерация выполняется последовательно. Если необходимо отметить возможность параллельного выполнения итерации, в языке UML используется символ "*||". Итерация не распространяется на вложенные уровни данного потока или нити. Каждый уровень должен иметь свое собственное представление для итеративного повторения процедурной последовательности.

  • Возвращаемое значение представляется в форме списка имен значений, возвращаемых по окончании коммуникации или взаимодействия в полной итерации данной процедурной последовательности. Эти идентификаторы могут выступать в качестве аргументов в последующих сообщениях. Если сообщение не возвращает никакого значения, то ни значение, ни оператор присваивания на диаграмме кооперации не указываются.

Например, сообщение

1.2.3: р:= найти_документ (спецификация_документа)

означает передачу вложенного сообщения с запросом поиска в базе данных нужного документа по его спецификации, причем источнику сообщения должен быть возвращен найденный документ.

  • Имя сообщения, записанное в сигнатуре после возвращаемого значения, означает имя события, которое инициируется объектом-получателем сообщения после его приема. Наиболее часто таким событием является вызов операции объекта. Это может быть реализовано различными способами, один из которых — вызов операции. Тогда соответствующая операция должна быть определена в том классе, которому принадлежит объект-получатель.
  • Список аргументов представляет собой разделенные запятыми и заключенные в круглые скобки действительные параметры той операции, вызов которой инициируется данным сообщением. Список аргументов может быть пустым, однако скобки все равно записываются. Для записи аргументов также может быть использован некоторый псевдокод или язык программирования.

Так, в приведенном выше примере сообщения

1.2.3: р:= найти_документ (спецификация_документа)

Аргумент найти_документ является именем сообщения, а специфика-ция_документа — списком аргументов, состоящим из единственного действительного параметра операции. При этом имя сообщения означает обращение к операции найти_ документ, которая должна быть определена в соответствующем классе объекта-получателя.

Примечание

На диаграмме кооперации при записи сообщений также могут использоваться • стереотипы, рассмотренные ранее при построении диаграммы последовательности (см. главу 8). Их семантика и синтаксис остаются без изменения, поскольку определены в нотации языка UML

9.5. Пример построения диаграммы кооперации

В качестве примера рассмотрим построение диаграммы кооперации для моделирования процесса телефонного разговора с использованием обычной телефонной сети (см. главу ф. Напомним, что объектами в этом примере являются два абонента а и Ь, два телефонных аппарата с и </, коммутатор и сам разговор как объект моделирования. При этом как коммутатор, так и разговор являются анонимными объектами.

На начальном этапе изобразим все объекты и связи между ними на диаграмме кооперации при помощи соответствующих обозначений (рис. 9.11). Заметим, что первый телефонный аппарат изображен как активный объект, а второй — как пассивный.

Рис. 9.11. Начальный фрагмент диаграммы кооперации для примера моделирования обычного телефонного разговора

В последующем необходимо специфицировать все связи на этой диаграмме, указав на их концах необходимую информацию в форме ролей связей. Дополненный таким образом вариант диаграммы кооперации изображен ниже (рис. 9.12). Заметим, что для объекта "Разговор" указано помеченное значение {transient}, которое означает, что этот объект создается в процессе выполнения объемлющего процесса и уничтожается до его завершения. Напомним, что помеченные значения (tagged values) являются стандартными элементами языка UML.

Рис. 9.12. фрагмент диаграммы кооперации, дополненный стереотипами ролей связей, именами ассоциаций и помеченным значением объекта

Рис. 9.13. Окончательный вариант диаграммы кооперации для моделирования телефонного разговора

Наконец, на диаграмму кооперации необходимо нанести все сообщения, указав их порядок и семантические особенности. Окончательный фрагмент диаграммы кооперации изображен на рис. 9.13 и содержит, строго говоря, модель кооперации только для начала разговора. Эта диаграмма может быть дополнена сообщениями, необходимыми для окончания разговора, что читателям предлагается выполнить самостоятельно в качестве упражнения.

Как нетрудно заметить, диаграмма кооперации для примера с телефонным разговором не содержит ни временных особенностей передачи сообщений, ни особенностей жизненного цикла участвующих в данной кооперации объектов. Поэтому может быть принято решение о том, что она является избыточной при наличии построенной диаграммы последовательности. Этот факт не вызывает сомнений в тех случаях, когда структура взаимодействующих объектов является достаточно тривиальной.

Если же взаимодействующие объекты образуют между собой различные типы отношений-ассоциаций (композиция, агрегация), то диаграмма кооперации оказывается необходимым представлением модели на всех ее уровнях.

9.6. Заключительные рекомендации по построению диаграмм кооперации

Построение диаграммы кооперации можно начинать сразу после построения диаграммы вариантов использования. В этом случае каждый из вариантов использования может быть специфицирован в виде отдельной диаграммы кооперации уровня спецификации. Эта диаграмма способствует более . полному пониманию особенностей реализации функций системой, хотя и не может содержать всю информацию, необходимую для их реализации.

В дальнейшем, после построения диаграммы классов, каждая из диаграмм кооперации может уточняться в виде соответствующей диаграммы уровня примеров. Важно понимать, что диаграмма кооперации этого уровня может содержать те и только те объекты и связи, которые уже определены на построенной ранее диаграмме классов. В противном случае, если возникает необходимость включения в диаграмму кооперации объектов, которые создаются на основе отсутствующих классов, соответствующие диаграммы классов должны быть модифицированы явным описанием этих классов.

Следует помнить, что на диаграмме кооперации изображаются только те объекты, которые непосредственно в ней участвуют. При этом объекты могут выступать в различных ролях, которые должны быть явно указаны на соответствующих концах связей диаграммы. Применение стереотипов унифицирует кооперацию, обеспечивая ее адекватную интерпретацию как со стороны заказчиков, так и со стороны разработчиков. Тем не менее, целесообразно различать терминологию, используемую на диаграммах кооперации уровня спецификации и уровня примеров.

Так, при построении диаграмм кооперации уровня спецификации желательно применять наиболее понятную заказчику терминологию, избегая технических фраз и словосочетаний. Например, "оформить заказ", "отгрузить товар", "представить отчет", "разработать план" и т. д. Такие известные разработчикам слова как "сервер", "защищенный протокол", "закрытая операция класса", а также стереотипы и помеченные значения на этом уровне применять не рекомендуется. На уровне спецификации нужно стремиться достичь по возможности полного взаимопонимания между заказчиком и командой разработчиков всех вариантов использования проектируемой системы в контексте их кооперации.

При построении диаграмм кооперации уровня примеров терминология должна наиболее точно отражать все аспекты реализации соответствующих объектов и связей. Поскольку диаграмма этого уровня является документацией для разработчиков системы, здесь допустимо использовать весь арсенал стереотипов, ограничений и помеченных значений, который имеется в языке UML. Если типовых обозначений недостаточно, разработчики могут дополнить диаграмму собственными элементами, используя механизм расширений языка UML.

Процесс построения диаграммы кооперации уровня примеров должен быть согласован с процессами построения диаграммы классов и диаграммы последовательности. В первом случае, как уже отмечалось, необходимо следить за использованием только тех объектов, для которых определены порождающие их классы. Во втором случае нужно согласовывать последовательности передаваемых сообщений. Речь идет о том, что не допускается различный порядок следования сообщений для моделирования одного и того же взаимодействия на диаграмме кооперации и диаграмме последовательности. Таким образом, диаграмма кооперации, с одной стороны, обеспечивает концептуально согласованный переход от статической модели диаграммы классов к динамическим моделям поведения, представляемым диаграммами последовательности, состояний и деятельности. С другой стороны, диаграмма этого типа предопределяет особенности реализации модели на диаграммах компонентов и развертывания, которые являются предметом рассмотрения в двух последующих главах книги.

На главную страницу