DOCSLIB.ORG

Consistent Architecture Diagrams for C++ Projects

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Consistent Architecture Diagrams for C++ Projects Consistent architecture diagrams for C++ projects Marius Feilhauer About me ￮ M.Sc. Automotive Engineering @ University Stuttgart ￮ PhD thesis Simulation-based validation of advanced driver assistance systems @ HLRS University Stuttgart (Prof. Resch) and ETAS GmbH ￮ Working experience @ Robert Bosch GmbH, Aston Martin Ltd. and Porsche AG ￮ Software developer of C++ based simulation models @ ETAS GmbH ￮ Lectures @ University Stuttgart Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 2 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Introduction and Overview Source Code Test Repository Build Tooling Download Server Build Scripts v1.0 v1.0 v1.1 v1.1 v1.2 v1.2 v2.0 v2.0 Documentation ? Diagrams Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 3 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Agenda ￮ Good documentation ￮ Architecture and code visualization ￮ Consistency ￮ Diagrams as code ￮ Takeaways & Outlook Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 4 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Good Documentation Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 5 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Golden nuggets Guiding principles by atlassian Keep it brief Visuals are key Know your audience www.atlassian.com/software/confluence/documentation Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 6 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Documentation use cases Two examples Mh, Cool new undocumented library functions I get this issue ah, we changed unprofessional this … Adam Scott, www.oreilly.com/ideas/the-eight-rules-of-good-documentation Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 7 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. The eight rules of good documentation 1. Write documentation that is inviting and clear 2. Write documentation that is comprehensive, detailing all aspects of the project 3. Write documentation that is skimmable 4. Write documentation that offers examples of how to use the software 5. Write documentation that has repetition, when useful 6. Write documentation that is up-to-date 7. Write documentation that is easy to contribute to 8. Write documentation that is easy to find Adam Scott, www.oreilly.com/ideas/the-eight-rules-of-good-documentation Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 8 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Fast understanding Professional Enforces to express of your intentions public image intentions precisely Additional benefits when using consistent diagrams within your documentation www.atlassian.com/software/confluence/documentation Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 9 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Diagrams and code visualization Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 10 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. UML Diagrams UML Diagram Overview Structure Diagram Behavior Diagram Class Diagram Use Case Diagram Object Diagram Activity Diagram Package Diagram State Machine Diagram Composite Structure Diagram Interaction Diagram Component Diagram Sequence Diagram Deployment Diagram Communication Diagram Timing Diagram Profile Diagram Interaction Overview Diagram based on www.uml-diagrams.org/uml-25-diagrams.html Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 11 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Grade System Example Use Case Diagram Madeline Adair, Use Case Diagrams, www.slideplayer.com/slide/677748 Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 12 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Shopping Example UML Component Diagram Example Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 13 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Abstract Factory Design Pattern UML Class Diagram Example Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 14 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Let’s get a coffee Activity Diagram Want some coffee Walk to the coffee machine Brew coffee want milk Add milk don’t like milk Take coffee want some sugar Add sugar no sugar for me Enjoy coffee Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 15 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Smart Home Example Deployment Diagram deployment Smart Home :PC :Tablet :Smartphone :Web Browser :Web Browser :Web Browser :Serv er :Web Service :IoT Controller «Sensor» «Sensor» «Sensor» «Sensor» :Temperature :Light :Contact :Humidity Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 16 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Diagrams allow to transport information easily and there are many different options available how to draw them Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 17 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Consistency Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 18 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Consistency Documentation Documentation v1.0 v1.1 Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 19 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Draw diagrams by using code Source code of diagrams has to be kept in-sync with the rest of the code and its documentations Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 20 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Diagrams as code Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 21 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Overview Diagrams as code ￮ Available tools allow automated generation of diagrams Doxygen, CMake, PlantUML ￮ Easy integration into existing build toolchains ￮ Automatic approaches vs. scripted diagrams Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 22 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Example project Directory structure Example Vehicle Traffic Light Vehicle Garage Vehicle Creator Race Game CMake Documentation DependencyGraph Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 23 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications for industrial property rights. Example project CMake targets Executable Executable Race Game Vehicle Creator Dynamic Library Static Library Traffic Light Vehicle Garage Dynamic Library Vehicle Public | Dr. Marius C. Feilhauer - ETAS/ETS-Fe | 2019-11-15 24 © ETAS GmbH 2019. All rights reserved, also regarding any disposal, exploitation, reproduction, editing, distribution, as wel l as in the event of applications
Load more

Recommended publications
  • An Optimal Control Approach for Determiniation of the Heat Loss Coefficient in an Ics Solar Domesticater W Heating System
    University of Central Florida STARS Electronic Theses and Dissertations, 2004-2019 2010 An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domesticater W Heating System Camilo Gil University of Central Florida Part of the Electrical and Electronics Commons Find similar works at: https://stars.library.ucf.edu/etd University of Central Florida Libraries http://library.ucf.edu This Doctoral Dissertation (Open Access) is brought to you for free and open access by STARS. It has been accepted for inclusion in Electronic Theses and Dissertations, 2004-2019 by an authorized administrator of STARS. For more information, please contact [email protected]. STARS Citation Gil, Camilo, "An Optimal Control Approach For Determiniation Of The Heat Loss Coefficient In An Ics Solar Domestic Water Heating System" (2010). Electronic Theses and Dissertations, 2004-2019. 4297. https://stars.library.ucf.edu/etd/4297 AN OPTIMAL CONTROL APPROACH FOR DETERMINATION OF THE HEAT LOSS COEFFICIENT IN AN ICS SOLAR DOMESTIC WATER HEATING SYSTEM by CAMILO GIL B.S. Pontificia Universidad Javeriana, 2001 M.S. University of New Mexico, 2005 A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Electrical and Computer Engineering in the College of Engineering and Computer Science at the University of Central Florida Orlando, Florida Summer Term 2010 Major Professor: Marwan Simaan ©2010 Camilo Gil ii ABSTRACT Water heating in a typical home in the U.S. accounts for a significant portion (between 14% and 25%) of the total home’s annual energy consumption. The objective of considerably reducing the home’s energy consumption from the utilities calls for the use of onsite renewable energy systems.
    [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]
  • Development of an Entity Component System Architecture for Realtime Simulation
    Fachbereich 4: Informatik Development of an Entity Component System Architecture for Realtime Simulation Bachelorarbeit zur Erlangung des Grades Bachelor of Science (B.Sc.) im Studiengang Computervisualistik vorgelegt von Trevor Hollmann Erstgutachter: Prof. Dr.-Ing. Stefan Müller (Institut für Computervisualistik, AG Computergraphik) Zweitgutachter: Kevin Keul, M.Sc. (Institut für Computervisualistik, AG Computergraphik) Koblenz, im September 2019 Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Ja Nein Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. .................................................................................... (Ort, Datum) (Unterschrift) Abstract The development of a game engine is considered a non-trivial problem. [3] The architecture of such simulation software must be able to manage large amounts of simulation objects in real-time while dealing with “crosscutting concerns” [3, p. 36] between subsystems. The use of object oriented paradigms to model simulation objects in class hierar- chies has been reported as incompatible with constantly changing demands dur- ing game development [2, p. 9], resulting in anti-patterns and eventual, messy re-factoring. [13] Alternative architectures using data oriented paradigms re- volving around object composition and aggregation have been proposed as a result. [13, 9, 1, 11] This thesis describes the development of such an architecture with the explicit goals to be simple, inherently compatible with data oriented design, and to make reasoning about performance characteristics possible. Concepts are for- mally defined to help analyze the problem and evaluate results. A functional implementation of the architecture is presented together with use cases common to simulation software. Zusammenfassung Die Entwicklung einer Spiele-Engine wird als nichttriviales Problem betrach- tet.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [Show full text]
  • 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.
    [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]
  • 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
    [Show full text]
  • Affordit!: a Tool for Authoring Object Component Behavior in Virtual
    AffordIt!: A Tool for Authoring Object Component Behavior in Virtual Reality * † ‡ § Sina Masnadi Andres´ N. Vargas Gonzalez´ Brian Williamson Joseph J. LaViola Jr. Department of Computer Science University of Central Florida (a) (b) (c) (d) Figure 1: These figures show a sequence of steps followed to add a rotation affordance to the door of a washer machine. (a) An object in the scenario (b) Cylinder shape selection wrapping the door. (c) A user sets the amount of rotation the door will be constrained to. (d) An animation generated from the affordance can be visualized. ABSTRACT realistic experiences necessary to a VR scene, but not asset creation In this paper we present AffordIt!, a tool for adding affordances (a situation described in Hughes et al. [17]) which are needed to to the component parts of a virtual object. Following 3D scene build a virtual scene. To alleviate this problem, recent research has been focusing on frameworks to ease users’ authoring process as reconstruction and segmentation procedures, users find themselves with complete virtual objects, but no intrinsic behaviors have been seen in [9, 12, 35]. 3D scene reconstruction [32, 34, 44, 49] provides assigned, forcing them to use unfamiliar Desktop-based 3D editing a suitable solution to the problem. Initially a 3D reconstructed tools. AffordIt! offers an intuitive solution that allows a user to environment will be composed of a continuous mesh which can be segmented via autonomous tools as shown in George et al. [10] and select a region of interest for the mesh cutter tool, assign an intrinsic behavior and view an animation preview of their work.
    [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]
  • 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.
    [Show full text]
  • 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.
    [Show full text]