DOCSLIB.ORG

UML Profile for AUTOSAR V1.0.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UML Profile for AUTOSAR V1.0.1 UML Profile for AUTOSAR V1.0.1 Document Title UML Profile for AUTOSAR Document Owner AUTOSAR GbR Document Responsibility AUTOSAR GbR Document Version 1.0.1 Document Status Final Document Change History Date Version Changed by Change Description 27.06.2006 1.0.1 AUTOSAR Layout Adaptations Administration 28.04.2006 1.0.0 AUTOSAR Initial release Administration 1 of 93 AUTOSAR_UML_Profile - AUTOSAR confidential - UML Profile for AUTOSAR V1.0.1 Disclaimer This specification as released by the AUTOSAR Development Partnership is intended for the purpose of information only. The use of material contained in this specification requires membership within the AUTOSAR Development Partnership or an agreement with the AUTOSAR Development Partnership . The AUTOSAR Development Partnership will not be liable for any use of this Specification. Following the completion of the development of the AUTOSAR Specifications commercial exploitation licenses will be made available to end users by way of written License Agreement only. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher. The word AUTOSAR and the AUTOSAR logo are registered trademarks. Copyright © 2004-2006 AUTOSAR Development Partnership. All rights reserved. Advice to users of AUTOSAR Specification Documents: AUTOSAR Specification Documents may contain exemplary items (exemplary reference models, "use cases", and/or references to exemplary technical solutions, devices, processes or software). Any such exemplary items are contained in the Specification Documents for illustration purposes only, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such Specification Documents, nor any later AUTOSAR compliance certification of products actually implementing such exemplary items, imply that intellectual property rights covering such exemplary items are licensed under the same rules as applicable to the AUTOSAR Standard. 2 of 93 AUTOSAR_UML_Profile - AUTOSAR confidential - UML Profile for AUTOSAR V1.0.1 Abstract This document describes a UML 2.0 Profile for AUTOSAR, initially covering the V2.0 AUTOSAR basic software feature list. 3 of 93 AUTOSAR_UML_Profile - AUTOSAR confidential - UML Profile for AUTOSAR V1.0.1 Table of Contents 1. Introduction.......................................................................................................... 8 1.1. Goals............................................................................................................ 8 1.2. Scope ........................................................................................................... 8 1.3. Terminology ................................................................................................. 8 2. Example use of the Profile................................................................................. 10 3. Software Component Model .............................................................................. 14 3.1. Compositions ............................................................................................. 14 3.1.1. ComponentType (from Components).................................................. 14 3.1.2. ComponentPrototype (from Composition)........................................... 15 3.1.3. CompositionType (from Composition)................................................. 16 3.1.4. AtomicSoftwareComponentType (from Components)......................... 16 3.1.5. SensorActuatorSoftwareComponentType (from Components) ........... 17 3.2. Ports and Connectors................................................................................. 18 3.2.1. PortPrototype (from Components) ...................................................... 19 3.2.2. PPortPrototype (from Components) .................................................... 20 3.2.3. ServerPort........................................................................................... 20 3.2.4. ReceiverPort ....................................................................................... 21 3.2.5. RPortPrototype (from Components).................................................... 21 3.2.6. ClientPort ............................................................................................ 22 3.2.7. SenderPort.......................................................................................... 22 3.2.8. ConnectorPrototype (from Composition)............................................. 22 3.2.9. AssemblyConnectorPrototype (from Composition) ............................. 23 3.2.10. DelegationConnectorPrototype (from Composition) ........................ 24 3.3. Interfaces ................................................................................................... 25 3.3.1. PortInterface (from PortInterface)........................................................ 26 3.3.2. SenderReceiverInterface (from PortInterface)..................................... 27 3.3.3. DataPrototype (from Datatype::Datatypes) ......................................... 28 3.3.4. DataElementPrototype (from PortInterface) ........................................ 28 3.3.5. ClientServerInterface (from PortInterface) .......................................... 28 3.3.6. OperationPrototype (from PortInterface) ............................................. 29 3.3.7. ArgumentPrototype (from PortInterface) ............................................. 29 3.4. Data Types................................................................................................. 30 3.4.1. PrimitiveType (from Datatype::Datatypes) .......................................... 31 3.4.2. Range (from Datatype::Datatypes)...................................................... 32 3.4.3. BooleanType (from Datatype::Datatypes) ........................................... 32 3.4.4. IntegerType (from Datatype::Datatypes) ............................................. 33 3.4.5. RealType (from Datatype::Datatypes)................................................. 33 3.4.6. OpaqueType (from Datatype::Datatypes) ........................................... 33 3.4.7. PrimitiveTypeWithSemantics (from Datatype::Datatypes)................... 34 3.4.8. EnumerationType................................................................................ 34 3.5. Internal Behavior ........................................................................................ 35 3.5.1. InternalBehavior (from InternalBehavior) ............................................ 35 3.5.2. Implementation (from InternalBehavior:: Implementation)................... 36 3.5.3. ResourceConsumption (from InternalBehavior::Implementation)........ 37 3.5.4. Code (from InternalBehavior::Implementation).................................... 37 4 of 93 AUTOSAR_UML_Profile - AUTOSAR confidential - UML Profile for AUTOSAR V1.0.1 3.5.5. The Runnable Entities......................................................................... 38 3.5.6. Data access ........................................................................................ 40 3.5.7. RTE Events......................................................................................... 45 4. ECU Model ........................................................................................................ 50 4.1. ECUResourceTemplate – General Elements............................................. 50 4.1.1. HWElement (from ECUResourceTemplate)........................................ 50 4.1.2. HWElementContainer (from ECUResourceTemplate) ........................ 51 4.1.3. ECU (from ECUResourceTemplate) ................................................... 51 4.1.4. HWPort (from ECUResourceTemplate) .............................................. 52 4.1.5. AssemblyHWConnection (from ECUResourceTemplate) ................... 53 4.2. Sensor Actuator.......................................................................................... 54 4.2.1. SensorActuatorHW (from ECUResourceTemplate::Sensor Actuator). 54 4.2.2. ActuatorHW (from ECUResourceTemplate::Sensor Actuator)............ 54 4.2.3. SensorHW (from ECUResourceTemplate::Sensor Actuator).............. 54 4.2.4. DisplayHW (from ECUResourceTemplate::Sensor Actuator).............. 54 4.3. Memory ...................................................................................................... 55 4.3.1. MemoryMappedHWPort (from ECUResourceTemplate::Memory)...... 55 4.3.2. MemoryMappedAssemblyHWConnection (from ECUResourceTemplate::Memory) .................................................................... 55 4.3.3. ProvidedMemorySegment (from ECUResourceTemplate::Memory)... 55 4.3.4. ProvidedNVMemorySegment (from ECUResourceTemplate::Memory).. ............................................................................................................ 56 4.4. Basic Elements........................................................................................... 56 4.4.1. ErrorDetectionCorrection (from ECUResourceTemplate::Basic Elements) .......................................................................................................... 56 4.5. ECU Electronics ......................................................................................... 56 4.5.1. ECUElectronics (from ECUResourceTemplate::ECU Electronics)..... 56 4.5.2. Clock (from ECUResourceTemplate::ECU Electronics)...................... 57 4.6. Peripherals ................................................................................................
Load more

Recommended publications
  • Datatypes (Pdf Format)
    Basic Scripting, Syntax, and Data Types in Python Mteor 227 – Fall 2020 Basic Shell Scripting/Programming with Python • Shell: a user interface for access to an operating system’s services. – The outer layer between the user and the operating system. • The first line in your program needs to be: #!/usr/bin/python • This line tells the computer what python interpreter to use. Comments • Comments in Python are indicated with a pound sign, #. • Any text following a # and the end of the line is ignored by the interpreter. • For multiple-line comments, a # must be used at the beginning of each line. Continuation Line • The \ character at the end of a line of Python code signifies that the next line is a continuation of the current line. Variable Names and Assignments • Valid characters for variable, function, module, and object names are any letter or number. The underscore character can also be used. • Numbers cannot be used as the first character. • The underscore should not be used as either the first or last character, unless you know what you are doing. – There are special rules concerning leading and trailing underscore characters. Variable Names and Assignments • Python is case sensitive! Capitalization matters. – The variable f is not the same as the variable F. • Python supports parallel assignment >>> a, b = 5, 'hi' >>> a 5 >>> b 'hi' Data Types • Examples of data types are integers, floating-point numbers, complex numbers, strings, etc. • Python uses dynamic typing, which means that the variable type is determined by its input. – The same variable name can be used as an integer at one point, and then if a string is assigned to it, it then becomes a string or character variable.
    [Show full text]
  • 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]
  • Customizing UML with Stereotypes
    Customizing UML with Stereotypes Mirosáaw StaroĔ ii iii Blekinge Institute of Technology Dissertation Series No 2003:06 ISSN 1650-2140 ISBN 91-7295-028-5 Customizing UML with Stereotypes Mirosáaw StaroĔ Department of Software Engineering and Computer Science Blekinge Institute of Technology Sweden iv BLEKINGE INSTITUTE OF TECHNOLOGY Blekinge Institute of Technology, situated on the southeast coast of Sweden, started in 1989 and in 1999 gained the right to run Ph.D programmes in technology. Research programmes have been started in the following areas: • Applied signal processing • Computer science • Computer systems technology • Design and digital media • Human work science with a special focus on IT • IT and gender research • Mechanical engineering • Software engineering • Spatial planning • Telecommunication systems Research studies are carried out in all faculties and about a third of the annual budget is dedicated to research. Blekinge Institute of Technology S-371 79 Karlskrona, Sweden http://www.bth.se v Jacket illustration: © 2003 GillWorth gallery, www.gillworthreptiles.co.uk Publisher: Blekinge Institute of Technology Printed by Kaserntryckeriet, Karlskrona, Sweden 2003 ISBN 91-7295-028-5 vi Abstract The Unified Modeling Language (UML) is a visual modeling language for documenting and specifying software. It is gaining popularity as a language for a variety of purposes. It was designed as a result of a unifying activity in the last decade. Since this general purpose language cannot suit all possible needs, it has built-in mechanisms for providing extensibility for specific purposes. One such mechanism is the notion of stereotype, which is a means of branding the existing model element with a new semantics.
    [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]
  • A Model-Driven Engineering Approach to Support the Verification of Compliance to Safety Standards
    A Model-Driven Engineering Approach to Support the Verification of Compliance to Safety Standards Rajwinder Kaur Panesar-Walawege, Mehrdad Sabetzadeh, Lionel Briand Simula Research Laboratory, Lysaker, Norway University of Oslo, Norway Email: {rpanesar,mehrdad,briand}@simula.no Abstract—Certification of safety-critical systems according to system development. This means that they will have to well-recognised standards is the norm in many industries where reconstruct the missing evidence after the fact. Doing so the failure of such systems can harm people or the environment. is often very expensive, and the outcomes might be far Certification bodies examine such systems, based on evidence that the system suppliers provide, to ensure that the relevant from satisfactory. On the certifier side, poorly structured and safety risks have been sufficiently mitigated. The evidence is incomplete evidence often leads to significant delays and aimed at satisfying the requirements of the standards used loss of productivity, and further may not allow the certifier for certification, and naturally a key prerequisite for effective to develop enough trust in the system that needs to be collection of evidence is that the supplier be aware of these certified. It is therefore very important to devise a systematic requirements and the evidence they require. This often proves to be a very challenging task because of the sheer size of the methodology, which is amenable to effective automated standards and the fact that the textual standards are amenable support, to specify, manage, and analyze the safety evidence to subjective interpretation. In this paper, we propose an ap- used to demonstrate compliance to standards.
    [Show full text]
  • MPLAB C Compiler for PIC24 Mcus and Dspic Dscs User's Guide
    MPLAB® C Compiler for PIC24 MCUs and dsPIC® DSCs User’s Guide 2002-2011 Microchip Technology Inc. DS51284K Note the following details of the code protection feature on Microchip devices: • Microchip products meet the specification contained in their particular Microchip Data Sheet. • Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the intended manner and under normal conditions. • There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip’s Data Sheets. Most likely, the person doing so is engaged in theft of intellectual property. • Microchip is willing to work with the customer who is concerned about the integrity of their code. • Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not mean that we are guaranteeing the product as “unbreakable.” Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of our products. Attempts to break Microchip’s code protection feature may be a violation of the Digital Millennium Copyright Act. If such acts allow unauthorized access to your software or other copyrighted work, you may have a right to sue for relief under that Act. Information contained in this publication regarding device Trademarks applications and the like is provided only for your convenience The Microchip name and logo, the Microchip logo, dsPIC, and may be superseded by updates.
    [Show full text]
  • UML Notation Guide 3
    UML Notation Guide 3 This guide describes the notation for the visual representation of the Unified Modeling Language (UML). This notation document contains brief summaries of the semantics of UML constructs, but the UML Semantics chapter must be consulted for full details. Contents This chapter contains the following topics. Topic Page “Part 1 - Background” “Introduction” 3-5 Part 2 - Diagram Elements “Graphs and Their Contents” 3-6 “Drawing Paths” 3-7 “Invisible Hyperlinks and the Role of Tools” 3-7 “Background Information” 3-8 “String” 3-8 “Name” 3-9 “Label” 3-10 “Keywords” 3-11 “Expression” 3-11 “Type-Instance Correspondence” 3-14 Part 3 - Model Management March 2003 OMG-Unified Modeling Language, v1.5 3-1 3 UML Notation Guide Topic Page “Package” 3-16 “Subsystem” 3-19 “Model” 3-24 Part 4 - General Extension Mechanisms “Constraint and Comment” 3-26 “Element Properties” 3-29 “Stereotypes” 3-31 Part 5 - Static Structure Diagrams “Class Diagram” 3-34 “Object Diagram” 3-35 “Classifier” 3-35 “Class” 3-35 “Name Compartment” 3-38 “List Compartment” 3-38 “Attribute” 3-41 “Operation” 3-44 “Nested Class Declarations” 3-48 “Type and Implementation Class” 3-49 “Interfaces” 3-50 “Parameterized Class (Template)” 3-52 “Bound Element” 3-54 “Utility” 3-56 “Metaclass” 3-57 “Enumeration” 3-57 “Stereotype Declaration” 3-57 “Powertype” 3-61 “Class Pathnames” 3-61 “Accessing or Importing a Package” 3-62 “Object” 3-64 “Composite Object” 3-67 “Association” 3-68 “Binary Association” 3-68 3-2 OMG-Unified Modeling Language, v1.5 March 2003 3 UML Notation Guide
    [Show full text]
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • 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.
    [Show full text]
  • UML Profile for Communicating Systems a New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols
    UML Profile for Communicating Systems A New UML Profile for the Specification and Description of Internet Communication and Signaling Protocols Dissertation zur Erlangung des Doktorgrades der Mathematisch-Naturwissenschaftlichen Fakultäten der Georg-August-Universität zu Göttingen vorgelegt von Constantin Werner aus Salzgitter-Bad Göttingen 2006 D7 Referent: Prof. Dr. Dieter Hogrefe Korreferent: Prof. Dr. Jens Grabowski Tag der mündlichen Prüfung: 30.10.2006 ii Abstract This thesis presents a new Unified Modeling Language 2 (UML) profile for communicating systems. It is developed for the unambiguous, executable specification and description of communication and signaling protocols for the Internet. This profile allows to analyze, simulate and validate a communication protocol specification in the UML before its implementation. This profile is driven by the experience and intelligibility of the Specification and Description Language (SDL) for telecommunication protocol engineering. However, as shown in this thesis, SDL is not optimally suited for specifying communication protocols for the Internet due to their diverse nature. Therefore, this profile features new high-level language concepts rendering the specification and description of Internet protocols more intuitively while abstracting from concrete implementation issues. Due to its support of several concrete notations, this profile is designed to work with a number of UML compliant modeling tools. In contrast to other proposals, this profile binds the informal UML semantics with many semantic variation points by defining formal constraints for the profile definition and providing a mapping specification to SDL by the Object Constraint Language. In addition, the profile incorporates extension points to enable mappings to many formal description languages including SDL. To demonstrate the usability of the profile, a case study of a concrete Internet signaling protocol is presented.
    [Show full text]
  • UML 2001: a Standardization Odyssey
    UML 2001: A Standardization Odyssey As the UML reaches the ripe age of four, both its proponents and its critics are scanning the recent changes in the UML 1.3 revision. CRIS KOBRYN In a relatively short period of time the Unified Modeling Language has emerged as the software industry’s dominant modeling language. UML is not only a de facto modeling language standard; it is fast becoming a de jure standard. Nearly two years ago the Object Management Group (OMG) adopted UML as its standard modeling language. As an approved Publicly Available Specification (PAS) submitter to the International Organization for Standardization (ISO), the OMG is proposing the UML specification for international timescales of standards usually conflict with the standardization. It is anticipated that the “fast competitive need to use the latest technology as track” PAS process will complete sometime next early as possible. From a technical perspective, the year, at which time UML will be formally recog- need to achieve consensus encourages “design by nized as an international standard for information committee” processes. In this sort of environment, technology. sound technical tradeoffs are often overridden by The major benefits of international standardiza- inferior political compromises. Too frequently the tion for a specification include wide recognition and resulting specifications become bloated with patches acceptance, which typically enlarge the market for in a manner similar to the way laws become fattened products based on it. However, these benefits often with riders in “pork belly” legislation. demand a high price. Standardization processes are This article explores how the UML is faring in typically formal and protracted, seeking to accom- the international standardization process.
    [Show full text]
  • Software II: Principles of Programming Languages
    Software II: Principles of Programming Languages Lecture 6 – Data Types Some Basic Definitions • A data type defines a collection of data objects and a set of predefined operations on those objects • A descriptor is the collection of the attributes of a variable • An object represents an instance of a user- defined (abstract data) type • One design issue for all data types: What operations are defined and how are they specified? Primitive Data Types • Almost all programming languages provide a set of primitive data types • Primitive data types: Those not defined in terms of other data types • Some primitive data types are merely reflections of the hardware • Others require only a little non-hardware support for their implementation The Integer Data Type • Almost always an exact reflection of the hardware so the mapping is trivial • There may be as many as eight different integer types in a language • Java’s signed integer sizes: byte , short , int , long The Floating Point Data Type • Model real numbers, but only as approximations • Languages for scientific use support at least two floating-point types (e.g., float and double ; sometimes more • Usually exactly like the hardware, but not always • IEEE Floating-Point Standard 754 Complex Data Type • Some languages support a complex type, e.g., C99, Fortran, and Python • Each value consists of two floats, the real part and the imaginary part • Literal form real component – (in Fortran: (7, 3) imaginary – (in Python): (7 + 3j) component The Decimal Data Type • For business applications (money)
    [Show full text]