Unified Modeling Language (UML) Object Diagram and Interaction

Total Page:16

File Type:pdf, Size:1020Kb

Unified Modeling Language (UML) Object Diagram and Interaction Object Diagram Interaction Diagrams Unified Modeling Language (UML) Object Diagram and Interaction Diagrams Miaoqing Huang University of Arkansas Spring 2010 1 / 17 Object Diagram Interaction Diagrams Outline 1 Object Diagram 2 Interaction Diagrams Sequence Diagram Communication Diagram 2 / 17 Object Diagram Interaction Diagrams Outline 1 Object Diagram 2 Interaction Diagrams Sequence Diagram Communication Diagram 3 / 17 Object Diagram Interaction Diagrams Object Diagram A snapshot of the objects in a system at a point in time Object: instance of a class Notation Object name is underlined instance name : class name Both parts of the name are optional EndsAt StartsAt StartsAt EndsAt 4 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Outline 1 Object Diagram 2 Interaction Diagrams Sequence Diagram Communication Diagram 5 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram UML Diagrams Class Object Use Case Diagram Diagram Diagram Sequence Communication Diagram Diagram 6 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Purpose of Sequence Diagram Static diagram Use case diagrams show the static relationship between actors and use cases Class diagrams show the static relationship between classes or instances A program is a sequence of interactions among objects (i.e., instances of classes) Difficult of find a program only with static diagrams Purpose of sequence diagram Model the high-level interaction between active objects in a system Model the high-level interaction between subsystems 7 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Sequence Diagram Example sd Create new agreement :RecordAgreement :RecordAgreement first:CarSharer :Journey UI Control CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged 8 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Notation Frame sd Create new agreement :RecordAgreement :RecordAgreement first:CarSharer :Journey UI Control CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged Sequence diagrams are Time runs vertically drawn in frames Lifelines are arranged New in UML 2.0 horizontally Represent object instances 9 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Notation Frame sd Create new agreement :RecordAgreement :RecordAgreement first:CarSharer :Journey UI Control CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged Sequence diagrams are Time runs vertically drawn in frames Lifelines are arranged New in UML 2.0 horizontally Represent object instances 10 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Notation Lifeline Participating instances are represented by lifelines Dashed vertical line Rectangle representing an object Syntax Explanation o An object named o o : C An object named o of class C :C An anonymous object of class C 11 / 17 Different types of messages Synchronous Asynchronous Creation Reply Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Notation Messages and Activation box A message is shown using an arrow going from the sender to the receiver The activation box indicate the active period of the object An object may have more than one active operation at the same time 12 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Notation Messages and Activation box A message is shown using an arrow going from the sender to the receiver The activation box indicate the active period of the object An object may have more than one active operation at the same time Different types of messages Synchronous Asynchronous Creation Reply 13 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Sequence Diagram Example with Explicit Reply sd Create new agreement :RecordAgreement :RecordAgreement first:CarSharer :Journey UI Control CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged 14 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Notation Combined Fragments A sequence of messages can be combined into a fragment Loop, branches, ... sd Create new agreement :RecordAgreement :RecordAgreement first:CarSharer :Journey UI Control CarMatch Administrator new agreement details set create sharing agreement :SharingAgreement loop [i=1..no of car sharers] get car sharer ID find by ID get journey ID find by ID add journey set sharing agreement set first arranged 15 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Communication Diagram Notation Frame: same as sequence diagram Lifeline: almost same as sequence diagram, no dash line Link Use to link interacting objects Message: almost same as sequence diagram Sequence-expression: message Recurrence in sequence-expression sent iteratively: *[iteration-clause] (e.g., *[i:0..journeys.length]) sent depending on some guard condition, e.g., [dataArranged = null] 16 / 17 Object Diagram Sequence Diagram Interaction Diagrams Communication Diagram Communication Diagram Example sd Spool File to Printer 4: print(name) :WordProcessor :PrintSpooler 1: open(name) 2: write(document) 4.1: open(name) 3: close 4.2*[while not eof]:readBlock 4.3: print(block) 4.3: close 4.4: delete(name) :PrinterFile :Printer 17 / 17.
Recommended publications
  • 07 Requirements What About RFP/RFB/Rfis?
    CMPSCI520/620 07 Requirements & UML Intro 07 Requirements SW Requirements Specification • Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,”
    [Show full text]
  • Communication Diagram.Pdf
    TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia LAB 5: Interaction Diagram - UML Communication Diagram OBJECTIVES To understand the role of dynamic models in requirement analysis by reading and constructing UML Communication Diagram. INTRODUCTION Communication Diagram (a.k.a. Collaboration Diagram) Communication Diagram provides another way to model a scenario. Essentially is a part of Interaction Diagram (just like Sequence Diagram). Each object is represented by an object icon, and links are used to indicate communication paths on which messages are transmitted. Messages presented in the same way as those in sequence diagram. Formerly known as Collaboration Diagram in UML 1.x specification. Communication Diagram represents a combination of information taken from Use Case, Class and Sequence Diagrams describing both the static structure and dynamic behavior of the system. Comparing and Contrasting: Collaboration and Sequence Both diagrams show the same information: Objects/classes Messages Sequence Conditional Repetition Messages to self Sequence Diagram and Communication Diagram are two views of the same scenario. Collaboration diagrams emphasize who-is-talking-to-who. But the time-ordering of the messages who gets obscured. Sequence diagrams emphasize time-ordering. But the who-is-talking-to-who gets obscured. Use the diagram that you are most comfortable with. Structure and Notation of Communication Diagram Objects are named <an object name>:< its class> . Nor Samsiah Binti Sani 1 TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia Either <an object name> or <a class name> can be removed. Collaborations / communications are shown by lines between objects.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • PART 3: UML Dynamic Modelling Notations • State Machines/Statecharts • Collaboration Diagrams • Sequence Diagrams • Activity Diagrams
    PART 3: UML Dynamic Modelling Notations • State machines/statecharts • Collaboration diagrams • Sequence diagrams • Activity diagrams. Chapter 19 of the textbook is relevant to this part. 1 State machines • State machines describe dynamic behaviour of objects, show life history of objects over time + object communications. • Used for real-time system design (eg., robotics); GUI design (states represent UI screens/modes). Example shows simple state machine with two states, On and Off and transitions between them. 2 Switch Off swon swoff On Simple state machine 3 State machines Elements of a state machine are: States: Rounded-corner boxes, containing state name. Transitions: Arrows from one state, source of transition, to another, target, labelled with event that causes transition. Default initial state: State of object at start of its life history. Shown as target of transition from initial pseudostate (black filled circle). Termination of state machine can be shown by `bullseye' symbol. 4 State machines UML divides state machines into two kinds: 1. Protocol state machines { describe allowed life histories of objects of a class. Events on transitions are operations of that class, transitions may have pre and post conditions. Transitions cannot have generated actions (although we will allow this). 2. Behaviour state machines { describe operation execution/implementation of object behaviour. Transitions do not have postconditions, but can have actions. State machines describe behaviour of objects of a particular class, or execution processing of an operation. 5 State machines • Class diagrams describe system data, independently of time. • State machines show how system/objects can change over time. • Switch state machine is protocol state machine for objects of Switch class.
    [Show full text]
  • UML Tutorial: Sequence Diagrams
    UML Tutorial: Sequence Diagrams. Robert C. Martin Engineering Notebook Column April, 98 In my last column, I described UML Collaboration diagrams. Collaboration diagrams allow the designer to specify the sequence of messages sent between objects in a collaboration. The style of the diagram emphasizes the relationships between the objects as opposed to the sequence of the messages. In this column we will be discussing UML Sequence diagrams. Sequence diagrams contain the same information as Collaboration diagrams, but emphasize the sequence of the messages instead of the relationships between the objects. The Cellular Phone Revisited Here again is the final collaboration diagram from last column’s Cellular Phone example. (See Figure 1.) 1*:ButtonPressed() :DigitButton Digit:Button 1.1:Digit(code) Adapter 2:ButtonPressed() :SendButton Send:Button :Dialler Adapter 2.1:Send() 1.1.2:EmitTone(code) 2.1.1:Connect(pno) 1.1.1:DisplayDigit(code) 2.1.1.1:InUse() :Cellular display display:Dialler :Speaker Radio :CRDisplay Display Figure 1: Collaboration diagram of Cellular Phone. The Sequence diagram that corresponds to this model is shown in Figure 2. It is pretty easy to see what the diagrams in Figure 2 are telling us, especially when we compare them to Figure 1. Let’s walk through the features. First of all, there are two sequence diagrams present. The first one captures the course of events that takes place when a digit button is pressed. The second captures what happens when the user pushes the ‘send’ button in order to make a call. At the top of each diagram we see the rectangles that represent objects.
    [Show full text]
  • Unified Modeling Language 2.0 Part 1 - Introduction
    UML 2.0 – Tutorial (v4) 1 Unified Modeling Language 2.0 Part 1 - Introduction Prof. Dr. Harald Störrle Dr. Alexander Knapp University of Innsbruck University of Munich mgm technology partners (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 2 1 - Introduction History and Predecessors • The UML is the “lingua franca” of software engineering. • It subsumes, integrates and consolidates most predecessors. • Through the network effect, UML has a much broader spread and much better support (tools, books, trainings etc.) than other notations. • The transition from UML 1.x to UML 2.0 has – resolved a great number of issues; – introduced many new concepts and notations (often feebly defined); – overhauled and improved the internal structure completely. • While UML 2.0 still has many problems, current version (“the standard”) it is much better than what we ever had formal/05-07-04 of August ‘05 before. (c) 2005-2006, Dr. H. Störrle, Dr. A. Knapp UML 2.0 – Tutorial (v4) 3 1 - Introduction Usage Scenarios • UML has not been designed for specific, limited usages. • There is currently no consensus on the role of the UML: – Some see UML only as tool for sketching class diagrams representing Java programs. – Some believe that UML is “the prototype of the next generation of programming languages”. • UML is a really a system of languages (“notations”, “diagram types”) each of which may be used in a number of different situations. • UML is applicable for a multitude of purposes, during all phases of the software lifecycle, and for all sizes of systems - to varying degrees.
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis
    APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson Dissertation submitted to the faculty of the Virginia Polytechnic Institute and State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Engineering Sandeep K. Shukla, Chair Lamine Mili Alireza Haghighat Chao Wang Yi Deng April 3, 2015 Blacksburg, Virginia Keywords: AADL, CPS, Model-based code synthesis, correct-by-construction code synthesis, Polychrony, code generators, OSATE, Ocarina Copyright 2015, Matthew E. Anderson APECS: Polychrony based End-to-End Embedded System Design and Code Synthesis Matthew E. Anderson (ABSTRACT) The development of high integrity embedded systems remains an arduous and error-prone task, despite the efforts by researchers in inventing tools and techniques for design automa- tion. Much of the problem arises from the fact that the semantics of the modeling languages for the various tools, are often distinct, and the semantics gaps are often filled manually through the engineer's understanding of one model or an abstraction. This provides an op- portunity for bugs to creep in, other than standardising software engineering errors germane to such complex system engineering. Since embedded systems applications such as avionics, automotive, or industrial automation are safety critical, it is very important to invent tools, and methodologies for safe and reliable system design. Much of the tools, and techniques deal with either the design of embedded platforms (hardware, networking, firmware etc), and software stack separately. The problem of the semantic gap between these two, as well as between models of computation used to capture semantics must be solved in order to design safer embedded systems.
    [Show full text]
  • Systems Engineering with Sysml/UML Morgan Kaufmann OMG Press
    Systems Engineering with SysML/UML Morgan Kaufmann OMG Press Morgan Kaufmann Publishers and the Object Management Group™ (OMG) have joined forces to publish a line of books addressing business and technical topics related to OMG’s large suite of software standards. OMG is an international, open membership, not-for-profi t computer industry consortium that was founded in 1989. The OMG creates standards for software used in government and corporate environments to enable interoperability and to forge common development environments that encourage the adoption and evolution of new technology. OMG members and its board of directors consist of representatives from a majority of the organizations that shape enterprise and Internet computing today. OMG’s modeling standards, including the Unifi ed Modeling Language™ (UML®) and Model Driven Architecture® (MDA), enable powerful visual design, execution and maintenance of software, and other processes—for example, IT Systems Modeling and Business Process Management. The middleware standards and profi les of the Object Management Group are based on the Common Object Request Broker Architecture® (CORBA) and support a wide variety of industries. More information about OMG can be found at http://www.omg.org/. Related Morgan Kaufmann OMG Press Titles UML 2 Certifi cation Guide: Fundamental and Intermediate Exams Tim Weilkiens and Bernd Oestereich Real-Life MDA: Solving Business Problems with Model Driven Architecture Michael Guttman and John Parodi Architecture Driven Modernization: A Series of Industry Case Studies Bill Ulrich Systems Engineering with SysML/UML Modeling, Analysis, Design Tim Weilkiens Acquisitions Editor: Tiffany Gasbarrini Publisher: Denise E. M. Penrose Publishing Services Manager: George Morrison Project Manager: Mónica González de Mendoza Assistant Editor: Matt Cater Production Assistant: Lianne Hong Cover Design: Dennis Schaefer Cover Image: © Masterfile (Royalty-Free Division) Morgan Kaufmann Publishers is an imprint of Eslsevier.
    [Show full text]
  • Towards Fixing Sketchy UML Models by Leveraging Textual Notations: Application to Real-Time Embedded Systems
    Towards Fixing Sketchy UML Models by Leveraging Textual Notations: Application to Real-Time Embedded Systems Fr´ed´ericJouault and J´er^ome Delatour PRES Universit´eNantes Angers Le Mans (UNAM) TRAME team, ESEO, Angers, France [email protected] Abstract. During the development of real-time embedded system, the use of UML models as blueprints is a common practice with a focus on un- derstandability rather than comprehensiveness. However, further in the development, these models must be completed in order to achieve the necessary validation and verification activities. They are typically per- formed by using several formal tools. Each tool needs models of the sys- tem at a given abstraction level, which are precise and complete enough wrt. how the tool processes them. If UML is appropriate for capturing multiple concerns, its multiple partial views without a global one in- crease the difficulty of locating inconsistency or incompleteness issues. Therefore, ensuring completeness is time consuming, fastidious, and er- ror prone. We propose an approach based on the use of a UML textual syntax closely aligned to its metamodel: tUML. An initial prototype is described, and examples are given. 1 Introduction Using sketchy models is common during software systems development. Such models (also called contemplative models) are just drawings that cannot be au- tomatically processed (e.g., transformed into code, or verified). In the use of such models as blueprints, the focus is on communication rather than on com- pleteness. The UML language is a good candidate for that kind of practice. It is primarily a graphical notation, and it offers a relatively large set of diagrams for representing various concerns.
    [Show full text]
  • Θέµα : Interaction Diagrams / State Machine Diagrams Ηµεροµηνία : 21
    ΗΥΗΥΗΥ -351: Ανάλυση και Σχεδίαση Πληροφοριακών Συστημάτων Information Systems Analysis and Design Πανεπιστήμιο Κρήτης , Φθινόπωρο 2005 Φροντιστήριο 5 Θέµα : Interaction Diagrams / State Machine Diagrams Ηεροµηνία : 21 Νοεµβρίου 2005 Outline • Interaction Diagrams – Sequence diagrams – Communication diagrams • State Machine Diagrams •For each Diagram •Definition •Elements •Demonstration •Tool tricks CS-351 University of Crete, Fall 2005-2006 2 Sequence Diagrams • Definition : An interaction diagram that represents objects as lifelines running down the page. • The interactions between the objects are represented as messages drawn as arrows from the source lifeline to the target lifeline. • Good at showing which objects communicate with which other objects and what messages trigger those communications. • NOT intended for showing complex procedural logic. CS-351 University of Crete, Fall 2005-2006 3 Sequence Diagrams • Lifelines • Messages – Execution Occurrence – Self Message – Lost and Found Messages • Lifeline Start and End • Duration and Time Constraints • Combined Fragments • Gate • Part Decomposition • State Invariant / Continuations CS-351 University of Crete, Fall 2005-2006 4 Sequence Diagrams - Lifelines • A lifeline represents an individual participant. If its name is self then that indicates that the lifeline represents the owner of the sequence diagram. • Sometimes a sequence diagram will have a lifeline with an actor element symbol at its head. This will usually be the case if the sequence diagram is owned by a use case. • Boundary,
    [Show full text]
  • UML Why Develop a UML Model?
    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes
    [Show full text]