DOCSLIB.ORG

UML Components

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
UML Components UML Components John Daniels Syntropy Limited [email protected] © Syntropy Limited 2001 All rights reserved Agenda • Aspects of a component • A process for component specification • Implications for the UML email:[email protected] Syntropy Limited Aspects of a component email:[email protected] Syntropy Limited UML Unified Modeling Language • The UML is a standardised language for describing the structure and behaviour of things • UML emerged from the world of object- oriented programming • UML has a set of notations, mostly graphical • There are tools that support some parts of the UML email:[email protected] Syntropy Limited Aspects of an Object ! Specification unit 1..* Interface ! Implementation unit * realization Class 0..1 Class Implementation source 1 1 instance * Object ! Execution unit email:[email protected] Syntropy Limited Components in context ObjectObject Evolving PrinciplesPrinciples developed within adopted by adopted by 1989- 1967- RMI 1995- Smalltalk EJB DistributedDistributed Object-orientedObject-oriented ObjectObject ComponentsComponents Programming DCOM Programming TechnologyTechnology C++ Java CORBA COM+/.NET Only interoperable Typically language neutral. A way of packaging within the language. Multiple address spaces. object implementations Single address space Non-integrated services to ease their use. Integrated services email:[email protected] Syntropy Limited Component standard features • Component Model: – defined set of services that support the software – set of rules that must be obeyed in order to take advantage of the services • Simple programming model, no need to design/know about the infrastructure • Services include: – remote access, transactions, persistent storage, security – typically use services by configuring not programming email:[email protected] Syntropy Limited Aspects of a component ! It has a specification spec ! It has an implementation for (int i=0; i<limit; i++) { list[i] = … ? ! It can be }; …… deployed ! It conforms to a standard Enterprise Component ! It can be Standard packaged into modules email:[email protected] Syntropy Limited Component forms 1..* Interface * realization 0..1 Class Class Implementation source 1 ! Specification unit 1 instance * Component 1..* Object Interface Specification * spec 1 ! Implementation unit * realization Component 0..1 Component Implementation source 1 1..* 1 1..* file Component Module instance * Component ! Packaging unit Object ! Execution unit email:[email protected] Syntropy Limited Two distinct contracts Usage contract: a contract between a component object’s interface and a client Interface Client Component <<use>> Spec <<realize>> Realization contract: a contract between a component specification and a Component component Interface email:[email protected] Syntropy Limited Interface specification We could specify placeOrder( ) IOrderMgt like this: placeOrder(custNum, prodNum, quan) “The number of orders for the numOfOrders(custNum): Integer customer is increased by one and a reserveStock message is sent to the component IProductMgt supporting the IProductMgt reserveStock(prodNum, quan) availableStock(prodNum): Integer interface” email:[email protected] Syntropy Limited Separation of specification concerns The client cares about this - it affects the subsequent result of numOfOrders( ). Therefore it is part of the usage contract “The number of orders for the customer is increased by one and a reserveStock message is sent to the component The IOrderMgt client does not care about supporting the IProductMgt this - but the implementer does. Therefore it is part of the realization interface” contract email:[email protected] Syntropy Limited Interfaces versus Component Specs Component Component Interface Specification • Represents the usage contract • Represents the realization • Provides a list of operations contract • Defines an underlying logical • Provides a list of supported information model specific to interfaces the interface • Defines the run-time unit • Specifies how operations • Defines the relationships affect or rely on the between the information models information model of different interfaces • Describes local effects only • Specifies how operations should be implemented in terms of usage of other interfaces email:[email protected] Syntropy Limited Contracts and roles Specifier (Architect) A person who produces the technical specification for a system or components within a system The Usage Contract The Realization Contract Client Realizer A person who writes A person who builds a software that uses a component that meets a component component specification email:[email protected] Syntropy Limited Component deployment Component 1..* 1..* Component 1 file Module 1 installed as copy * * Installed server Installed Component 1..* 1..* Module ! Registration unit ! Installation unit email:[email protected] Syntropy Limited Example - Microsoft Word wordDocument: Component wordApplication: Component file file winword.exe: installed as ComponentModule wordDocument: installed as InstalledComponent server copy wordApplication: C:/../winword.exe: InstalledComponent server InstalledModule instance instance applicationObject: docObject: ComponentObject File / New ComponentObject email:[email protected] Syntropy Limited Example - Enterprise Java Beans invoice: c:/../invoice.java: ComponentSpec realization ComponentImplementation invoiceBean: Component file invoice.jar: ComponentModule installed as copy invoiceBean: server c:/../invoice.jar: InstalledComponent InstalledModule instance invoiceABC: ComponentObject email:[email protected] Syntropy Limited A process for component specification email:[email protected] Syntropy Limited Application Architecture Layers Presentation Web Client HTTP Client Web Server RMI / IIOP / DCOM RMI / IIOP / DCOM Service Application Server Existing Any System (server) JDBC / ODBC / SQL Data Database Server email:[email protected] Syntropy Limited Application Blueprint Web Server A/JSP Application Server Component Object Component Object Component Object Component Object Component Object Existing Database System email:[email protected] Syntropy Limited Finer-Grain Application Layers Presentation UI Logic What the user sees User Interface Dialog Logic (UseCases) User Dialog Supports multiple UIs Transient Dialog State Service Business transactions System Services Allows multiple Dialogs (including Batch) Business Integrity State Business Services Sub-transactions Business Instance State Data email:[email protected] Syntropy Limited Management and Development Processes • Management Processes – Schedule work and plan deliveries – Allocate resources 0%% complete 100% Concept model – Monitor progress Use Case model Component specs – Control risk Components • Development Processes – Create working software from requirements – Focus on software development artifacts – Described independently of the management process – Defines ordering constraints and dependencies – Organized into Workflows Use Case models Specification Component specs & architectures Business Concept Workflow models email:[email protected] Syntropy Limited Workflows in the development process Business requirements Existing Artefact assets Requirements Business Concept User models interface Technical Components constraints Use Case Specification Provisioning Assembly models Component specs Assemblies & architectures Test Tested Workflow (c.f. RUP) assemblies Deployment email:[email protected] Syntropy Limited The Requirements Workflow Problem domain Business knowledge requirements Requirements Workflow Develop Business Develop business Concept Model processes Software boundary Identify Use Cases decisions Business Use Cases Concept Model email:[email protected] Syntropy Limited Business process We want to provide some automated support for managing hotel reservations Take up reservation customer arrives/ Wait for event enquiry/ [else] cancel request/ Check amendment availability request/ Cancel [suitable reservation room] Make Amend no show/ reservation reservation Confirm Process no Notify billing reservation show system email:[email protected] Syntropy Limited Business Concept Model 1 Hotel Chain 1..* Clerk 1..* 1 Hotel * contactedHotel 1 1 * * 1..* allocation Customer Reservation Room 1 * * 0..1 1 1 * * contactAddress 0..1 1 Address RoomType 1 0..1 1 Bill Payment 0..1 email:[email protected] Syntropy Limited Identify Use Cases A use case describes the interaction that follows from a single business event. Where an event triggers a number of process Take up reservation steps, all the steps form a single use case. customer arrives/ Wait for event enquiry/ [else] cancel request/ Check amendment availability request/ Cancel [suitable reservation room] Make Amend no show/ reservation reservation Confirm Process no Notify billing reservation show system email:[email protected] Syntropy Limited Reservation system Cancel a reservation ReservationMaker Use Case Make a diagram reservation Update a Guest reservation Take up a reservation BillingSystem Process no shows Add, amend, remove hotel, room, ReservationAdministrator customer, etc. email:[email protected] Syntropy Limited Name Make a Reservation Initiator Reservation Maker Goal Reserve a room at a hotel Steps Main success scenario or 1. Reservation Maker asks to make a reservation Extension 2. Reservation Maker selects hotel, dates and room type Points 3. System provides availability and price 4. Reservation Maker agrees to proceed 5. Reservation
Load more

Recommended publications
  • Uml.Sty, a Package for Writing UML Diagrams in LATEX
    uml.sty, a package for writing UML diagrams in LATEX Ellef Fange Gjelstad March 17, 2010 Contents 1 Syntax for all the commands 5 1.1 Lengths ........................................ 5 1.2 Angles......................................... 5 1.3 Nodenames...................................... 6 1.4 Referencepoints ................................. 6 1.5 Colors ......................................... 6 1.6 Linestyles...................................... 6 2 uml.sty options 6 2.1 debug ......................................... 6 2.2 index.......................................... 6 3 Object-oriented approach 7 3.1 Colors ......................................... 10 3.2 Positions....................................... 10 4 Drawable 12 4.1 Namedoptions .................................... 12 4.1.1 import..................................... 12 5 Element 12 5.1 Namedoptions .................................... 12 5.1.1 Reference ................................... 12 5.1.2 Stereotype................................... 12 5.1.3 Subof ..................................... 13 5.1.4 ImportedFrom ................................ 13 5.1.5 Comment ................................... 13 6 Box 13 6.1 Namedoptionsconcerninglocation . ....... 13 6.2 Boxesintext ..................................... 14 6.3 Named options concerning visual appearance . ......... 14 6.3.1 grayness.................................... 14 6.3.2 border..................................... 14 1 6.3.3 borderLine .................................. 14 6.3.4 innerBorder.................................
    [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]
  • 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]
  • Rational Unified Process - an Overview Uppsala, 2009-02-10
    Rational Unified Process - an overview Uppsala, 2009-02-10 Mikael Broomé Consultant M.Sc. LTH 10 years in Software Development 4 different RUP implementations Project Manager Mentor for Project Managers Applying more and more of agile mindset and techniques E-Mail: [email protected] 2 1 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 3 A good project delivers the right solution: satisified Users satisfied Sponsor delivers in time delivers on budget 4 2 Challenges Common challenges in software development projects: Capture the “right” requirements. Requirement changes. Different parts of the system do not fit together. Small changes causes big problems. Low quality and poor performance. Major problems identified late in projects. Lack of communication. Difficult to estimate time and cost. Management of environment, platforms and tools. 5 It’s all about (lack of) communication 6 3 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 7 What is RUP and UML? RUP is a process for development of software that describes what should be performed (activities) who should do it (roles) what the result should be (artifacts). UML is a notation with defined symbols that is worked out by OMG (Object Management Group) is used to make drawings (for example in software development). 8 4 Agenda Why a process for developing software? What is RUP? What is the “RUP-way” of developing software? How is RUP packaged? Advantages by using RUP? Challenges when using RUP? Relation to other processes? 9 JW2 RUP’s Six Best practices 1.
    [Show full text]
  • Network Visualization with R Katherine Ognyanova, POLNET 2015 Workshop, Portland OR
    Network visualization with R Katherine Ognyanova, www.kateto.net POLNET 2015 Workshop, Portland OR Contents Introduction: Network Visualization2 Data format, size, and preparation4 DATASET 1: edgelist ......................................4 DATASET 2: matrix .......................................5 Network visualization: first steps with igraph 5 A brief detour I: Colors in R plots8 A brief detour II: Fonts in R plots 11 Back to our main plot line: plotting networks 12 Plotting parameters ........................................ 12 Network Layouts ......................................... 17 Highlighting aspects of the network ............................... 24 Highlighting specific nodes or links ............................... 27 Interactive plotting with tkplot ................................. 29 Other ways to represent a network ............................... 30 Plotting two-mode networks with igraph ............................ 31 Quick example using the network package 35 Interactive and animated network visualizations 37 Interactive D3 Networks in R .................................. 37 Simple Plot Animations in R .................................. 38 Interactive networks with ndtv-d3 ................................ 39 Interactive plots of static networks............................ 39 Network evolution animations............................... 40 1 Introduction: Network Visualization The main concern in designing a network visualization is the purpose it has to serve. What are the structural properties that we want to highlight?
    [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]
  • 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]
  • Meta-Class Features for Large-Scale Object Categorization on a Budget
    Meta-Class Features for Large-Scale Object Categorization on a Budget Alessandro Bergamo Lorenzo Torresani Dartmouth College Hanover, NH, U.S.A. faleb, [email protected] Abstract cation accuracy over a predefined set of classes, and without consideration of the computational costs of the recognition. In this paper we introduce a novel image descriptor en- We believe that these two assumptions do not meet the abling accurate object categorization even with linear mod- requirements of modern applications of large-scale object els. Akin to the popular attribute descriptors, our feature categorization. For example, test-recognition efficiency is a vector comprises the outputs of a set of classifiers evaluated fundamental requirement to be able to scale object classi- on the image. However, unlike traditional attributes which fication to Web photo repositories, such as Flickr, which represent hand-selected object classes and predefined vi- are growing at rates of several millions new photos per sual properties, our features are learned automatically and day. Furthermore, while a fixed set of object classifiers can correspond to “abstract” categories, which we name meta- be used to annotate pictures with a set of predefined tags, classes. Each meta-class is a super-category obtained by the interactive nature of searching and browsing large im- grouping a set of object classes such that, collectively, they age collections calls for the ability to allow users to define are easy to distinguish from other sets of categories. By us- their own personal query categories to be recognized and ing “learnability” of the meta-classes as criterion for fea- retrieved from the database, ideally in real-time.
    [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]