DOCSLIB.ORG

Introduction to UML Lecture # 1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Introduction to UML Lecture # 1 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the book Applying UML and Patterns (3rd ed.) by C. Larman (2005). Modelling and Simulation, 2012 Introduction to Outline UML Course Course Information Information UML Structure UML Diagrams Behaviour Structure Diagrams Diagrams Interaction Behaviour Diagrams Diagrams Interaction Diagrams Modelling Use Case summary Modelling Use Case summary Introduction to UML Course Information UML Structure Diagrams Behaviour Course Information Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Aims and Objectives UML Course Information I To understand the software development process, UML Structure including requirement specification, analysis, design, Diagrams Behaviour implementation and testing. Diagrams Interaction I To learn and use various methodologies in software Diagrams development, Modelling Use Case I To understand the process of modelling real world summary problems and systems using UML, I To develop skills on object oriented software development (OOSD). Introduction to Assesment UML Course Information UML Structure I Assignment: Diagrams Behaviour th I One long, report style assignment, 50% (due 1630 27 Diagrams Interaction September 2012) Diagrams I Exam: Modelling th Use Case I Final exam (Perception), 50% (2 hours, 1900-2100 27 summary September 2012) Introduction to Books UML Course Information I Applying UML and patterns by Craig Larman UML Structure I Object-Oriented Software Engineering { a use case Diagrams Behaviour driven approach (revised edition) by Ivar Jacobson Diagrams Interaction I UML Distilled (2nd Edition) by Martin Fowler Diagrams I Software Engineering (4th Edition) by Ian Sommerville Modelling Use Case I Developing Applications with Java and UML by Paul R summary and Reed Jr I Practical Software Engineering by Leszek A Maciaszek and Bruc Lee Liong Introduction to UML Course Information UML Structure Diagrams Behaviour UML Diagrams Interaction Diagrams Modelling Use Case summary Introduction to What is UML UML Course Information I UML stands for Unified Modelling Language. UML I An industry standard modelling language for Structure Diagrams object-oriented software engineering. Behaviour Diagrams I Developed in the mid-1990's and standardised in 1997 Interaction Diagrams (UML 1.1). Modelling I UML 2.x is the current revision in use (we will focus on Use Case UML 2.0, revision from 2005). summary I UML includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems. Introduction to List of object-oriented programming UML languages Course Information UML I Languages designed mainly for object-oriented Structure programming: Diagrams Behaviour I C++ Diagrams Interaction I Java Diagrams I C# Modelling I Python Use Case summary I Languages with some object-oriented features: I Visual Basic I Fortran I Perl I PHP Introduction to List of Unified Modelling Language UML tools Course NAME PLATFORM LICENSE Information UML ArgoUML Cross-platform (Java) Open source Structure Diagrams astah* Multi-platform Commercial, Free Community version Behaviour Diagrams Interaction Dia Cross-platform (GTK+) Open source Diagrams Modelling Modelio Windows, Linux Open source Use Case Rational Rhapsody Windows, Linux, MacOS X Commercial summary Software Ideas Modeler Windows, Linux Commercial, Freeware for non-commercial StarUML Windows Open source Umbrello UML Modeller Unix-like; Windows Open source Visual Paradigm for UML Cross-platform (Java) Commercial, Free Community Edition Introduction to UML 2.0 UML Course Information UML Structure I UML 2.0 defines thirteen types of diagrams: Diagrams Behaviour I divided into three categories: Diagrams I Six diagram types represent static application Interaction Diagrams structure; Modelling I Three diagram types represent general types of Use Case behaviour; summary I Four diagram types represent different aspects of interactions. Introduction to Class Diagram UML Course Information Shows a collection of static model elements such as classes UML Structure and types, their contents, and their relationships. Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Object Diagram UML Course Information Depicts objects and their relationships at a point in time, UML typically a special case of either a class diagram or a Structure Diagrams communication diagram. Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Component Diagram UML Depicts the components that compose an application, system, or enterprise. The components, their Course interrelationships, interactions, and their public interfaces are Information UML depicted. Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Composite Structure Diagram UML Course Information Depicts the internal structure of a classifier (such as a class, UML component, or use case), including the interaction points of Structure Diagrams the classifier to other parts of the system. Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Package Diagram UML Shows how model elements are organized into packages as Course well as the dependencies between packages. Information UML Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Deployment Diagram UML Shows the execution architecture of systems. This includes Course Information nodes, either hardware or software execution environments, UML as well as the middleware connecting them. Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Use Case Diagram UML Shows use cases, actors, and their interrelationships. Course Information UML Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Activity Diagram UML Depicts high-level business processes, including data flow, or Course to model the logic of complex logic within a system. Information UML Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to State Machine Diagram UML Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to Course as a state diagram, state chart diagram, or a state-transition Information UML diagram. Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Sequence Diagram UML Models the sequential logic, in effect the time ordering of Course messages between classifiers. Information UML Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Communication Diagram UML Shows instances of classes, their interrelationships, and the Course message flow between them. Communication diagrams Information UML typically focus on the structural organisation of objects that Structure send and receive messages. Formerly called a Collaboration Diagrams Behaviour Diagram. Diagrams Interaction Diagrams Modelling Use Case summary Introduction to Timing Diagram UML Course Information UML Structure Diagrams Behaviour Depicts the change in state or condition of a classifier Diagrams Interaction instance or role over time. Typically used to show the change Diagrams in state of an object over time in response to external events. Modelling Use Case summary Introduction to Interaction Overview Diagram UML A variant of an activity diagram which overviews the control flow within a system or business process. Each node/activity Course within the diagram can represent another interaction Information UML diagram. Structure Diagrams Behaviour Diagrams Interaction Diagrams Modelling Use Case summary Introduction to UML Course Information UML Structure Diagrams Behaviour Modelling Diagrams Interaction Diagrams Modelling Use Case summary Introduction to System development UML Course Information I System development is model building UML I Complexity of a large project Structure Diagrams I A large number of components Behaviour Diagrams I A large amount of team work Interaction Diagrams I Linguistic communication between teams or between team members is neither accurate nor reliable Modelling Use Case I Models are standard representations and they are accurate and reliable summary I Modelling is the process of developing a model I Various types of models for different purposes and stages in software development Introduction to Types of models UML I Various types of models Course I Requirement model describes Information I Users' requirements UML I Functionality Structure Diagrams I Analysis model gives Behaviour System specifications Diagrams I Interaction I A robust and changeable structure and structured Diagrams components Modelling Use Case I Design model presents summary I A refined structure to the current implementation environment I Implementation model documents I Details of how a design is implemented I Test model gives I Verification I Validation Introduction to Architecture UML Course Information I Architecture of a modelling language UML Structure I Model architecture is a set of modelling language, Diagrams Behaviour notation and modelling techniques. Diagrams I A modelling language contains: Interaction Diagrams I Syntax - how it looks Modelling I Semantics - what it means Use Case I Pragmatics - heuristics and rules of thumb for using it summary I UML I Unified Modelling Language
Recommended publications
  • 07 Requirements What About RFP/RFB/Rfis?

    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,”
  • Blurred Lines Between Role and Reality: a Phenomenological Study of Acting

    Blurred Lines Between Role and Reality: a Phenomenological Study of Acting

    Antioch University AURA - Antioch University Repository and Archive Student & Alumni Scholarship, including Dissertations & Theses Dissertations & Theses 2019 Blurred Lines Between Role and Reality: A Phenomenological Study of Acting Gregory Hyppolyte Brown Follow this and additional works at: https://aura.antioch.edu/etds Part of the Psychology Commons BLURRED LINES BETWEEN ROLE AND REALITY: A PHENOMENOLOGICAL STUDY OF ACTING A Dissertation Presented to the Faculty of Antioch University Santa Barbara In partial fulfillment of the requirements for the the degree of DOCTOR OF PSYCHOLOGY In CLINICAL PSYCHOLOGY by GREGORY HIPPOLYTE BROWN August 2019 This dissertation, by Gregory Hippolyte Brown, has been approved by the committee members signed below who recommend that it be accepted by the faculty of Antioch University Santa Barbara in partial fulfillment of requirements for the degree of DOCTOR OF PSYCHOLOGY Dissertation Committee: _________________________ Brett Kia-Keating, Ed.D. Chairperson __________________________ Sharleen O‘ Brien, Ph.D. Second Faculty __________________________ Thalia R. Goldstein, Ph.D. External Expert ii Copyright © 2019 Gregory Hippolyte Brown iii Abstract When an actor plays a character in a film, they try to connect with the emotions and behavioral patterns of the scripted character. There is an absence of literature regarding how a role influences an actor’s life before, during, and after film production. This study examined how acting roles might influence an actor during times on set shooting a movie or television series as well as their personal life after the filming is finished. Additionally the study considered the psychological impact of embodying a role, and whether or not an actor ever has the feeling that the performed character has independent agency over the actor.
  • Component Diagrams in UML

    Component Diagrams in UML

    9. UML Component Diagrams Page 1 of 4 Component Diagrams in UML The previous articles covered two of the three primary areas in which the UML diagrams are categorized (see Article 1)—Static and Dynamic. The remaining two UML diagrams that fall under the category of Implementation are the Component and Deployment diagrams. In this article, we will discuss the Component diagram. Basics The different high-level reusable parts of a system are represented in a Component diagram. A component is one such constituent part of a system. In addition to representing the high-level parts, the Component diagram also captures the inter- relationships between these parts. So, how are component diagrams different from the previous UML diagrams that we have seen? The primary difference is that Component diagrams represent the implementation perspective of a system. Hence, components in a Component diagram reflect grouping of the different design elements of a system, for example, classes of the system. Let us briefly understand what criteria to apply to model a component. First and foremost, a component should be substitutable as is. Secondly, a component must provide an interface to enable other components to interact and use the services provided by the component. So, why would not a design element like an interface suffice? An interface provides only the service but not the implementation. Implementation is normally provided by a class that implements the interface. In complex systems, the physical implementation of a defined service is provided by a group of classes rather than a single class. A component is an easy way to represent the grouping together of such implementation classes.
  • Xtuml: Current and Next State of a Modeling Dialect

    Xtuml: Current and Next State of a Modeling Dialect

    xtUML: Current and Next State of a Modeling Dialect Cortland Starrett [email protected] 2 Outline • Introduc)on • Background • Brief History • Key Players • Current State • Related Modeling Dialects • Next State • Conclusion [email protected] 3 Introduc)on [email protected] 4 Background • Shlaer-Mellor Method (xtUML) – subject maers, separaon of concerns – data, control, processing – BridgePoint • data modeling (Object Oriented Analysis (OOA)) • state machines • ac)on language • interpre)ve execu)on • model compilaon [email protected] 5 History • 1988, 1991 Shlaer-Mellor Method published by Stephen Mellor and Sally Shlaer. • 2002 Executable UML established as Shlaer-Mellor OOA using UML notation. • 2004 Commercial Corporate Proprietary Licensed. • 2013 BridgePoint xtUML Editor goes open source under Apache 2.0. • 2014 all of BridgePoint (including Verifier and model compilers) goes open source under Apache and Creative Commons. • 2015 Papyrus Industry Consortium and xtUML/BridgePoint contribution • 2015 OSS of alternate generator engine (community building) • 2016 Papyrus-xtUML (BridgePoint) Eclipse Foundation governance • 2016 OSS contributions from industry, university and individuals [email protected] 6 Key Players • Saab • UK Crown • Agilent • Ericsson • Fuji-Xerox • Academia [email protected] 7 Current State • body of IP • self-hosng • Papyrus (and Papyrus Industry Consor)um) [email protected] 8 Related Dialects • MASL • Alf • UML-RT [email protected]
  • Using the UML for Architectural Description?

    Using the UML for Architectural Description?

    Using the UML for Architectural Description? Rich Hilliard Integrated Systems and Internet Solutions, Inc. Concord, MA USA [email protected] Abstract. There is much interest in using the Unified Modeling Lan- guage (UML) for architectural description { those techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. IEEE P1471, the Recommended Practice for Architectural Description, represents an emerging consensus for specifying the content of an architectural descrip- tion for a software-intensive system. Like the UML, IEEE P1471 does not prescribe a particular architectural method or life cycle, but may be used within a variety of such processes. In this paper, I provide an overview of IEEE P1471, describe its conceptual framework, and investigate the issues of applying the UML to meet the requirements of IEEE P1471. Keywords: IEEE P1471, architectural description, multiple views, view- points, Unified Modeling Language 1 Introduction The Unified Modeling Language (UML) is rapidly maturing into the de facto standard for modeling of software-intensive systems. Standardized by the Object Management Group (OMG) in November 1997, it is being adopted by many organizations, and being supported by numerous tool vendors. At present, there is much interest in using the UML for architectural descrip- tion: the techniques by which architects sketch, capture, model, document and analyze architectural knowledge and decisions about software-intensive systems. Such techniques enable architects to record what they are doing, modify or ma- nipulate candidate architectures, reuse portions of existing architectures, and communicate architectural information to others. These descriptions may the be used to analyze and reason about the architecture { possibly with automated support.
  • Guidelines for UML Or Sysml Modelling Within an Enterprise Architecture

    Guidelines for UML Or Sysml Modelling Within an Enterprise Architecture

    Guidelines for UML or SysML modelling within an enterprise architecture Mälardalen University Academy of Innovation, Design and Technology Author: Charlie Höglund Email: [email protected] Bachelor of Science in Computer Science/Basic level, 15hp Date: 2017-06-08 Examiner: Jan Carlson Supervisor: Daniel Sundmark Company supervisor: Fredric Andréasson (Volvo Construction Equipment) Abstract Enterprise Architectures (EA) are used to describe an enterprise’s structure in a standardized way. An Enterprise Architecture also provides decision-support when choosing a direction or making changes at different levels of an enterprise, such as the business architecture or technology architecture level. This can involve decisions such as: What kind of enterprise should this be, what kind of technologies should be used for new system developments etcetera. Therefore, using the Unified Modelling Language (UML) or Systems Modelling Language (SysML) together with standardized guidelines that help you decide what to do before, during, and after modelling could be important for producing correct and useful system models, which later on will be used to develop actual systems. At the moment, standardized guidelines of this kind do not really exist. However, there are a lot of information about why you should use UML or SysML, what kinds of UML or SysML diagrams that exist, or what notations to follow when creating a specific UML or SysML diagram. In this thesis, the objective has been to research about the usefulness and creation of standardized guidelines for UML or SysML modelling in an Enterprise Architecture (i.e. mainly intended for the automotive industry domain). For this reason, the two research questions: “how can you create useful standardized guidelines for UML or SysML modelling?” and “what do useful standardized guidelines for UML or SysML modelling look like?” were chosen.
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007

    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.
  • VI. the Unified Modeling Language UML Diagrams

    VI. the Unified Modeling Language UML Diagrams

    Conceptual Modeling CSC2507 VI. The Unified Modeling Language Use Case Diagrams Class Diagrams Attributes, Operations and ConstraintsConstraints Generalization and Aggregation Sequence and Collaboration Diagrams State and Activity Diagrams 2004 John Mylopoulos UML -- 1 Conceptual Modeling CSC2507 UML Diagrams I UML was conceived as a language for modeling software. Since this includes requirements, UML supports world modeling (...at least to some extend). I UML offers a variety of diagrammatic notations for modeling static and dynamic aspects of an application. I The list of notations includes use case diagrams, class diagrams, interaction diagrams -- describe sequences of events, package diagrams, activity diagrams, state diagrams, …more... 2004 John Mylopoulos UML -- 2 Conceptual Modeling CSC2507 Use Case Diagrams I A use case [Jacobson92] represents “typical use scenaria” for an object being modeled. I Modeling objects in terms of use cases is consistent with Cognitive Science theories which claim that every object has obvious suggestive uses (or affordances) because of its shape or other properties. For example, Glass is for looking through (...or breaking) Cardboard is for writing on... Radio buttons are for pushing or turning… Icons are for clicking… Door handles are for pulling, bars are for pushing… I Use cases offer a notation for building a coarse-grain, first sketch model of an object, or a process. 2004 John Mylopoulos UML -- 3 Conceptual Modeling CSC2507 Use Cases for a Meeting Scheduling System Initiator Participant
  • Sysml, the Language of MBSE Paul White

    Sysml, the Language of MBSE Paul White

    Welcome to SysML, the Language of MBSE Paul White October 8, 2019 Brief Introduction About Myself • Work Experience • 2015 – Present: KIHOMAC / BAE – Layton, Utah • 2011 – 2015: Astronautics Corporation of America – Milwaukee, Wisconsin • 2001 – 2011: L-3 Communications – Greenville, Texas • 2000 – 2001: Hynix – Eugene, Oregon • 1999 – 2000: Raytheon – Greenville, Texas • Education • 2019: OMG OCSMP Model Builder—Fundamental Certification • 2011: Graduate Certification in Systems Engineering and Architecting – Stevens Institute of Technology • 1999 – 2004: M.S. Computer Science – Texas A&M University at Commerce • 1993 – 1998: B.S. Computer Science – Texas A&M University • INCOSE • Chapters: Wasatch (2015 – Present), Chicagoland (2011 – 2015), North Texas (2007 – 2011) • Conferences: WSRC (2018), GLRCs (2012-2017) • CSEP: (2017 – Present) • 2019 INCOSE Outstanding Service Award • 2019 INCOSE Wasatch -- Most Improved Chapter Award & Gold Circle Award • Utah Engineers Council (UEC) • 2019 & 2018 Engineer of the Year (INCOSE) for Utah Engineers Council (UEC) • Vice Chair • Family • Married 14 years • Three daughters (1, 12, & 10) 2 Introduction 3 Our Topics • Definitions and Expectations • SysML Overview • Basic Features of SysML • Modeling Tools and Techniques • Next Steps 4 What is Model-based Systems Engineering (MBSE)? Model-based systems engineering (MBSE) is “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” -- INCOSE SE Vision 2020 5 What is Model-based Systems Engineering (MBSE)? “Formal systems modeling is standard practice for specifying, analyzing, designing, and verifying systems, and is fully integrated with other engineering models. System models are adapted to the application domain, and include a broad spectrum of models for representing all aspects of systems.
  • AP42 Section: Reference

    AP42 Section: Reference

    AP42 Section: 13.2.1 Reference: 8 Title: Paved Road Particulate Emissions, C. Cowherd, Jr., and P. J. Englehart, EPA-600/7-84-077, U. S. Environmental Protection Agency, Cincinnati, OH, July 1984. United Slates EPA-600 17- 84-077 Environmental Protection Agency July 1984 PAVED ROADS eEPA Research and Ap-42 Section 11.2.51\ Reference Number Development 4 iI J PAVED ROAD PARTICULATE EMISSIONS Source Category Report Prepared for Office of Air Quality Planning and Standards Prepared by Industrial Environmental Research Laboratory Research Triangle Park NC 2771 1 RESEARCH REPORTING SERIES Research reports of the Office of Research and Development, US. Environmental Protection Agency, have been grouped into nine series. These nine broad cate- gories were established to facilitate further development and application of en- vironmental technology. Elimination of traditional grouping was consciously planned to foster technology transfer and a maximum interface in related fields. The nine series are: 1. Environmental Health Effects Research 2. Environmental Protection Technology 3. Ecological Research 4. Environmental Monitoring .. 5. Socioeconomic Environmental Studies 6. Scientific and Technical Assessment Reports (STAR) 7. Interagency Energy-Environment Research and Development 8. “Special” Reports 9. Miscellaneous Reports This report has been assigned to the INTERAGENCY ENERGY-ENVIRONMENT RESEARCH AND DEVELOPMENT series. Reports in this series result from the effort funded under the 17-agency Federal Energy/Environment Research and Development Program. These studies relate to EPA’s mission to protect the public health and welfare from adverse effects of pollutants associated with energy sys- tems. The goal of the Program is to assure the rapid development of domestic energy supplies in an environmentally-compatible manner by providing the nec- essary environmental data and control technology.
  • Modelling Interactions

    Modelling Interactions

    University of Toronto Department of Computer Science Lecture 15: Modelling System Interactions Interactions with the new system How will people interact with the system? When/Why will they interact with the system? Use Cases introduction to use cases identifying actors identifying cases Advanced features Sequence Diagrams Temporal ordering of events involved in a use case © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 University of Toronto Department of Computer Science Moving towards specification What functions will the new system provide? How will people interact with it? Describe functions from a user’s perspective UML Use Cases Used to show: the functions to be provided by the system which actors will use which functions Each Use Case is: a pattern of behavior that the new system is required to exhibit a sequence of related actions performed by an actor and the system via a dialogue. An actor is: anything that needs to interact with the system: a person a role that different people may play another (external) system. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2 University of Toronto Department of Computer Science Use Case Diagrams Capture the relationships between actors and Use Cases Change a client contact Campaign Staff contact Manager Add a new client Record client payment Accountant © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 University of Toronto Department of Computer Science Notation for Use Case Diagrams Use case Change client contact Staff contact Actor Communication association System boundary © 2004-5 Steve Easterbrook.
  • Plantuml Language Reference Guide (Version 1.2021.2)

    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