DOCSLIB.ORG

Unified Modeling Language (UML)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Unified Modeling Language (UML) Troy Mockenhaupt Chi-Hang ( Alex) Lin Pejman ( PJ ) Yedidsion Overview Definition History Behavior Diagrams Interaction Diagrams Structural Diagrams Tools Effect on Software Engineering Definition A standard language for specifying, visualizing, and constructing software artifacts Non-restrictive Expressive and visual modeling language Independent of language and process History First modeling languages emerge 1970s “method wars” of the 1990s Methods began merging techniques 1994 – Booch and Rumbaugh unify Booch and Object Modeling Technique 1995-1996 Jacobson incorporates OOSE methods – term UML is coined 1997 – Object Management Group (OMG) accepted UML as standard History (cont.) UML 2.0 adopted in 2005 2.1.1 and 2.1.2 in 2007 ( never formally released ) UML 2.2 in 2009 UML 2.3 in 2010 UML 2.4.1 2011 UML 1.x vs 2.x 1.x vs 2.x Significant changes 1.x 2.x Activity Diagram Specialized form of Increasing the scope State Diagrams of usage Package Diagram Insufficient for large Added models Component Diagram No port and Added connectors Timing Diagram No syntax for timing Added purposes Behavior Diagrams ● Activity Diagram (basic program flow & capture decision points) ● Use Case Diagram (model user/system interactions) ● State Machine Diagram (“run state” of a model when it executes) Activity Diagram ● Shows the overall flow of control ● Comprises: choice, iteration, and concurrency ● Business and operational step-by-step workflows of components in a system ● A form of flowchart that has capability to express concurrency ● Graphical representations of workflows of stepwise activities and actions Activity Diagram (cont.) ● Similar to state machine diagrams ● Business process modeling ● Object-oriented equivalent of flow charts and data flow diagrams from structured development Activity Diagram (cont.) Use Case Diagram ● Interaction of users with the system ● Contains different types of users and the various ways they interact with the system ● Depicts Actors and their goals represented as use cases, as well as any dependencies among those use cases o Actors - entities external to the system Use Case Diagram (cont.) ● A use case typically includes: o Name and Description o Requirements (formal functional requirements) o Constraints (condition or restriction) o Scenarios (formal description of the flow of events) o Scenario diagrams (specific sequence of events between the system and the external actors) o Additional information (case specific) Use Case Diagram (cont.) ● Not a standalone model, but one that can be used in conjunction with other models ● Outline general behavior, therefore use case diagram should “focus on business goals rather than system goals” ● Not a technical outline of functionality, but provides the business reasoning and outcomes of the system Use Case Diagram (cont.) State Machine Diagram ● Nodes denote states ● Connectors denote state transitions ● Behavioral state machines o used to model the behavior of individual entities ● Protocol state machines o used to express usage protocols State Machine Diagram (cont.) ● Organize the way a device, computer program, or other (often technical) process works--always in exactly one of a number of possible states ● Overcome some of the limitations of traditional finite-state machines ● Support actions that depend on both the state of the system and the triggering event State Machine Diagram (cont.) ● Initial &Final States ● Transitions ● State Actions State Machine Diagram (cont.) Interaction Diagrams Communication Diagram Interaction Overview Diagram Sequence Diagram Timing Diagram Communication Diagram Interactions between objects in terms of sequenced messages Combination of info from Class, Sequence, and Use Case Diagrams Free-form arrangement of objects Chronological numbered labeling Similar to Sequence diagrams with focus on element interaction Communication Diagram (cont.) Interaction Overview Diagram Visualize control flow with nodes Frames of interaction diagrams Interaction diagrams are building blocks Deconstruct complex scenarios Activity diagram – initial, join, fork, decision, merge, and final Interaction occurrences and elements Interaction Overview Diagram(cont.) Sequence Diagram Detailed flow for use case realization Two-Dimensional Object instances and interactions Interaction order Sequence of object interactions Object lifelines Sequence Diagram (cont.) Timing Diagram Explore behavior of one or more objects during a given time period Similar to sequence diagram with axes reversed Concise and Robust notation Timing Diagram (cont.) Concise Notation Timing Diagram (cont.) Structural Diagram ● Class Diagram ● Object Diagram ● Composite Structure Diagram ● Component Diagram ● Package Diagram ● Deployment Diagram ● Profile Diagram Class Diagram ● Define Classes Diagram ● Introduce Class Diagram 1. Notations ● Relationships between classes Class Diagram (cont.) ● Class Diagram describes set of classes, interfaces and their relationships ● Class Diagram Notations: 1. Class Name 2. Properties of the classes with data types 3. Method names with data types 4. Visibility: +, #, ~, - (in the order of visibility) 5. Static members Class Diagram (cont.) Class Diagram (cont.) ● Dependency – A class needs to know about another class ● Association – A class contains the reference of an object to another class ● Aggregation – A class owns another class ● Composition – A class is made of other classes ● Inheritance – A class is a type of another class ● Constraints – 1. Invariants – must always be true 2. Pre conditions – check before execution 3. Post conditions – checked after execution ● Abstract Classes – Generic class, leaves implementation for sub classes ● Interfaces – Defines methods which must be implemented Class Diagram (cont.) Relationships between classes Class Diagram (cont.) Object Diagram ● Define Object Diagram: 1. Bringing classes to life 2. Demonstrates an instance of a class at a particular point of time ● Introduce Object Diagram Properties / Syntax: 1. Object, Object:Class, :Class 2. Links (Association) 3. Notes, Note connector 4. Use Object Constraint Language (OCL) Object Diagram (cont.) Composite Structure Diagram ● Define Composite Diagram 1. How objects create a big picture 2. How objects work together to achieve goals ● Deficiency of Class Diagram ● Introduce Composite Diagram ● Class Diagram V.S. Composite Diagram Composite Structure Diagram (cont.) Composite Structure Diagram (cont.) Component Diagram ● Define Component Diagram 1. Shows key components of a system 2. High-level picture of a system 3. Manage complexity and dependencies 4. Manageable, reusable and swappable 5. Good candidates are frequently used functionality: logger, XML parser, and shopping carts Component Diagram (cont.) ● Introduce Component Diagram 1. Components 2. Interfaces a. Provider interfaces (ball) on the left b. Required interfaces (socket) on the right 3. Dependencies and Inheritance a. Model dependencies from left to right b. Place child components below parent component c. Components should only depend on interfaces Component Diagram (cont.) A simple e-commerce system Package Diagram ● Define Package Diagram: 1. Organize most UML elements 2. Manage dependencies among packages 3. Package related elements into groups Package Diagram (cont.) ● Manage dependencies among packages 1. Avoid too many dependencies 2. Avoid cycles Package Diagram (cont.) Package related elements into groups: Package Diagram with Use Cases Deployment Diagram ● Define Deployment Diagram: Demonstrates the physical deployment of artifacts on nodes ● Introduce Deployment Diagram 1. Artifact – physical files that execute or used by software, e.g. .exe, .jar, .dlls, .java, .cpp, .xml, .txt 2. Node – hardware or software resources that can host software or related files, e.g. server, disk drives, OS, web server, application server 3. Device Node – physical resource (hardware) with processing capability 4. Execution environment– web server, application server, OS ● When to use Deployment Diagrams? Deployment Diagram (cont.) Early stage Deployment Diagram (cont.) Late stage Profile Diagram ● Define Profile Diagram: Customizes UML for a specific platform ● Introduce Profile Diagram: 1. Stereotypes – indicates a special usage 2. Tagged Values – additional information about the stereotype 3. Constraints ● Why Profile Diagram? Plug-ins, OMG profiles UML Tools ● Software applications that support some or all of the notations and semantics ● Types of Functionality supported: ● Diagramming - creating and editing ● Round-trip engineering: Code generation- derives from the diagrams part or all of the source code for the software system Reverse engineering- reads program source code as input and derives model data and corresponding graphical UML diagrams UML Tools (cont.) ● Limitations: o UML diagrams lack the detail that is needed to contain the same information as is covered with the program source o Source code often has more detailed information than in design diagrams ● Future use and development of tools UML Tools (cont.) ● Examples of current UML modeling tools: IBM Rational Rose, ArgoUML, BOUML, Dia, Enterprise Architect, MagicDraw UML, Modelio, PowerDesigner, Rational Rhapsody, Rational Software Architect, StarUML, and Umbrello ● Examples of development environments offering UML modeling tools: Eclipse (also includes reverse engineering architecture), NetBeans, and Visual Studio UML Tools (cont.) Effect on
Recommended publications
  • 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
  • Model Based Systems Engineering Approach to Autonomous Driving

    Model Based Systems Engineering Approach to Autonomous Driving

    DEGREE PROJECT IN ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018 Model Based Systems Engineering Approach to Autonomous Driving Application of SysML for trajectory planning of autonomous vehicle SARANGI VEERMANI LEKAMANI KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Author Sarangi Veeramani Lekamani [email protected] School of Electrical Engineering and Computer Science KTH Royal Institute of Technology Place for Project Sodertalje, Sweden AVL MTC AB Examiner Ingo Sander School of Electrical Engineering and Computer Science KTH Royal Institute of Technology Supervisor George Ungureanu School of Electrical Engineering and Computer Science KTH Royal Institute of Technology Industrial Supervisor Hakan Sahin AVL MTC AB Abstract Model Based Systems Engineering (MBSE) approach aims at implementing various processes of Systems Engineering (SE) through diagrams that provide different perspectives of the same underlying system. This approach provides a basis that helps develop a complex system in a systematic manner. Thus, this thesis aims at deriving a system model through this approach for the purpose of autonomous driving, specifically focusing on developing the subsystem responsible for generating a feasible trajectory for a miniature vehicle, called AutoCar, to enable it to move towards a goal. The report provides a background on MBSE and System Modeling Language (SysML) which is used for modelling the system. With this background, an MBSE framework for AutoCar is derived and the overall system design is explained. This report further explains the concepts involved in autonomous trajectory planning followed by an introduction to Robot Operating System (ROS) and its application for trajectory planning of the system. The report concludes with a detailed analysis on the benefits of using this approach for developing a system.
  • Information Technology and Software Development

    Information Technology and Software Development

    Course Title: Information Technology and Software Development NATIONAL OPEN UNIVERSITY OF NIGERIA SCHOOL OF SCIENCE AND TECHNOLOGY COURSE CODE: CIT 703 COURSE TITLE: Information Technology and Software Development National Open University of Nigeria, Victoria Island, Lagos Page 1 Course Title: Information Technology and Software Development Course Code Course Title Information Technology and Software Development Course Developer/Writer Eze, Festus Chux Department of Computer Science Ebonyi State University Abakaliki Course Editor Programme Leader Course Coordinator National Open University of Nigeria, Victoria Island, Lagos Page 2 Course Title: Information Technology and Software Development Introduction Information Technology and Software Development is a three credit load course for all the students offering Post Graduate Diploma (PGD) in Computer Science, Information Technology and other allied courses. Software Development is a major branch in computing and information Technology. A software development professional oversees the processes of software development, the management of software development project, the maintenance of the installed software in an organisation. For sometime the field has been dominated with what is the definitive process of software development. Furthermore there has been the running battle between professionals and managers on who should control a software development project. There is an attempt to classify it as any other project that an organisation handles hence anybody could manage it. Whereas others see it as a highly professional issue that requires high precision in design, management and implementation. However, software development is all involving. It involves the user (client) whose interest is paramount. The developing organisation and her professionals ( team)are of great importance. Therefore a successful exercise can only take place when all these variegated interests are harmonised.
  • APECS: Polychrony Based End-To-End Embedded System Design and Code Synthesis

    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.
  • Sysml Distilled: a Brief Guide to the Systems Modeling Language

    Sysml Distilled: a Brief Guide to the Systems Modeling Language

    ptg11539604 Praise for SysML Distilled “In keeping with the outstanding tradition of Addison-Wesley’s techni- cal publications, Lenny Delligatti’s SysML Distilled does not disappoint. Lenny has done a masterful job of capturing the spirit of OMG SysML as a practical, standards-based modeling language to help systems engi- neers address growing system complexity. This book is loaded with matter-of-fact insights, starting with basic MBSE concepts to distin- guishing the subtle differences between use cases and scenarios to illu- mination on namespaces and SysML packages, and even speaks to some of the more esoteric SysML semantics such as token flows.” — Jeff Estefan, Principal Engineer, NASA’s Jet Propulsion Laboratory “The power of a modeling language, such as SysML, is that it facilitates communication not only within systems engineering but across disci- plines and across the development life cycle. Many languages have the ptg11539604 potential to increase communication, but without an effective guide, they can fall short of that objective. In SysML Distilled, Lenny Delligatti combines just the right amount of technology with a common-sense approach to utilizing SysML toward achieving that communication. Having worked in systems and software engineering across many do- mains for the last 30 years, and having taught computer languages, UML, and SysML to many organizations and within the college setting, I find Lenny’s book an invaluable resource. He presents the concepts clearly and provides useful and pragmatic examples to get you off the ground quickly and enables you to be an effective modeler.” — Thomas W. Fargnoli, Lead Member of the Engineering Staff, Lockheed Martin “This book provides an excellent introduction to SysML.
  • UML Cheatsheet

    UML Cheatsheet

    UML Cheatsheet Class Diagram Elements dependency multiplicity association Package::AbstractClass -Attribute : Type 1 -ClassAttribute : Type Parent Child parent child* +Operation(Arg:Type):Type #AbstractOperation * role Association generalization Class visibility 0..1 info <<interface>> Note ChildInfo SubClass Interface realizes qualified association dependency T 1 Interface ParameterizedClass Value key Implementor Operation(Arg: T) Operation2(): T Sequence Diagram Elements Object : Class Object2 object creation call(obj) new incoming message Object3 selfCall callback interaction frame return object destruction loop / alt / opt delete frame type {constraint} callUnderConstraint {alternative} callUnderAlternative (cc) 2006 Lou Franco - Some Rights Reserved - Attribution-NonCommercial-ShareAlike 2.5 (cc) 2006 Lou Franco - Some Rights Reserved - Attribution-NonCommercial-ShareAlike 2.5 http://creativecommons.org/licenses/by-nc-sa/2.5/ http://creativecommons.org/licenses/by-nc-sa/2.5/ Package Diagram Elements dependency Data View Model SQLServer Oracle Object Diagram Elements John : Child name = "John" parent: Parent Mary : Child name = "Mary" Use Case Diagram Elements system boundary actor 1 Library checkout 1 Membership <<include>> Common return start : Date Role Use Case Use Case renewal : Date * LendRecord Role Lendable due : Date <<include>> id 1 returned : Boolean newArrival : Boolean * LendRecord(lendable, member, date) calcDueDate(member): Date isDue() : Boolean Use Case Use Case renew(Date) * Role Book CD 1 Role * Member DVD (cc) 2006
  • What Is Package Diagram? How to Draw Package Diagram?

    What Is Package Diagram? How to Draw Package Diagram?

    Visual Paradigm Tutorial What is Package Diagram? How to Draw Package Diagram? What is Package Diagram? How to Draw Package Diagram? Written Date : July 29, 2014 At the beginning of the project, you only have a limited number of diagrams and everything is simple and beautiful. However, when time flies, more and more diagrams have been created and they start to become unmanageable. As a result, your project becomes hard to navigate and diagrams become difficult to locate when you want to review or make changes. How can we fix it up? We can make use of the Package Diagram to organize your diagrams into different packages. This helps you in categorizing your diagrams according to their natures, making them easier to be navigated and located. The Package Diagram also serves as a catalog for you to jump to the diagram that you want to look at. In this tutorial, we will show you how this can be done. Create Packages for your diagrams First, we need to have our packages ready. To create packages: 1. To create a Package Diagram, select Diagram > New from the toolbar. 2. In the New Diagram window, select Package Diagram and click Next. https://www.visual-paradigm.com/tutorials/packagediagram.jsp Page 1 of 11 Visual Paradigm Tutorial What is Package Diagram? How to Draw Package Diagram? 3. Enter Racing Game Packages as diagram name and click OK to confirm. 4. Click the Package button in diagram tool bar, then click on the blank area of the diagram to create the package. 5. Name the package as Race.
  • Getting Started with Sysml 3 This Chapter Provides an Introduction to Sysml and Guidance on How to Begin Modeling in Sysml

    Getting Started with Sysml 3 This Chapter Provides an Introduction to Sysml and Guidance on How to Begin Modeling in Sysml

    CHAPTER Getting Started with SysML 3 This chapter provides an introduction to SysML and guidance on how to begin modeling in SysML. The chapter provides a brief overview of SysML, and then introduces a simplified version of the language we refer to as SysML-Lite, along with a simplified example, and tool tips on how to capture the model in a typical modeling tool. This chapter also introduces a simplified model-based systems engineering (MBSE) method that is consistent with the systems engineering process described in Chapter 1, Section 1.2. The chapter finishes by describing some of the challenges involved in learning SysML and MBSE. 3.1 SYSML PURPOSE AND KEY FEATURES SysML1 is a general-purpose graphical modeling language that supports the analysis, specification, design, verification, and validation of complex systems. These systems may include hardware, soft- ware, data, personnel, procedures, facilities, and other elements of man-made and natural systems. The language is intended to help specify and architect systems and specify their components that can then be designed using other domain-specific languages such as UML for software design and VHDL and three-dimensional geometric modeling for hardware design. SysML is intended to facilitate the application of an MBSE approach to create a cohesive and consistent model of the system that yields the benefits described in Chapter 2, Section 2.1.2. SysML can represent the following aspects of systems, components, and other entities: n Structural composition, interconnection, and classification n Function-based, message-based, and state-based behavior n Constraints on the physical and performance properties n Allocations between behavior, structure, and constraints n Requirements and their relationship to other requirements, design elements, and test cases 3.2 SYSML DIAGRAM OVERVIEW SysML includes nine diagrams as shown in the diagram taxonomy in Figure 3.1.
  • Standardized Technical Architecture Modeling Conceptual and Design Level

    Standardized Technical Architecture Modeling Conceptual and Design Level

    Standardized Technical Architecture Modeling Conceptual and Design Level Version 1.0 March 2007 Copyright 2007 SAP AG. All Rights Reserved No part of this document may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
  • Examples of UML Diagrams

    Examples of UML Diagrams

    UML Diagrams Examples Examples by Technology or Application Domain Online shopping UML diagrams Ticket vending machine UML diagrams Bank ATM UML diagrams Hospital management UML diagrams Digital imaging and communications in medicine (DICOM) UML diagrams Java technology UML diagrams Application development for Android UML diagrams Software licensing and protection using SafeNet Sentinel HASP security solution Examples by Types of Diagrams Activity diagram examples Class diagram examples Communication diagram examples Component diagram examples Composite structure diagram examples Deployment diagram examples Information flow diagram example Interaction overview diagram examples Object diagram example Package diagram examples Profile diagram examples http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 1 of 33 Sequence diagram examples State machine diagram examples Timing diagram examples Use case diagram examples Use Case Diagrams Business Use Case Diagrams Airport check-in and security screening business model Restaurant business model System Use Case Diagrams Ticket vending machine http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 2 of 33 Bank ATM UML use case diagrams examples Point of Sales (POS) terminal e-Library online public access catalog (OPAC) http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 3 of 33 Online shopping use case diagrams Credit card processing system Website administration http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 4 of 33 Hospital
  • UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process

    UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process

    VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS Introduction to OOAD – Unified Process - UML diagrams – Use Case – Class Diagrams– Interaction Diagrams – State Diagrams – Activity Diagrams – Package, component and Deployment Diagrams. INTRODUCTION TO OOAD ANALYSIS Analysis is a creative activity or an investigation of the problem and requirements. Eg. To develop a Banking system Analysis: How the system will be used? Who are the users? What are its functionalities? DESIGN Design is to provide a conceptual solution that satisfies the requirements of a given problem. Eg. For a Book Bank System Design: Bank(Bank name, No of Members, Address) Student(Membership No,Name,Book Name, Amount Paid) OBJECT ORIENTED ANALYSIS (OOA) Object Oriented Analysis is a process of identifying classes that plays an important role in achieving system goals and requirements. Eg. For a Book Bank System, Classes or Objects identified are Book-details, Student-details, Membership-Details. OBJECT ORIENTED DESIGN (OOD) Object Oriented Design is to design the classes identified during analysis phase and to provide the relationship that exists between them that satisfies the requirements. Eg. Book Bank System Class name Book-Bank (Book-Name, No-of-Members, Address) Student (Name, Membership No, Amount-Paid) OBJECT ORIENTED ANALYSIS AND DESIGN (OOAD) • OOAD is a Software Engineering approach that models an application by a set of Software Development Activities. YEAR/SEM: III/V CS6502-OOAD Page 1 VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE • OOAD emphasis on identifying, describing and defining the software objects and shows how they collaborate with one another to fulfill the requirements by applying the object oriented paradigm and visual modeling throughout the development life cycles.