How to Build a UML Model Announcements Rational Unified

Total Page:16

File Type:pdf, Size:1020Kb

How to Build a UML Model Announcements Rational Unified Announcements How to build a UML model ❚ HW3 – Phase 1 due on Feb 6th, 5:00pm (need to create new pairs, accounts) ❚ Feedback on M2: turn procedural code RUP into OO code, Planning game (show tables Steriotypes, packages, and with features, subtasks, estimates, object diagrams actuals, pair-programming partners) Case study ❚ Register for the Feb 18 Industry Reception 1 CS361 7-2 Rational Unified Process How RUP builds a model ❚ Designed to work with UML ❚ Gather use cases from customer ❚ No longer being promoted by IBM ❚ Make initial object model ❚ Roles - (out of 20 or so) ❚ For each use case: ❙ Architect ❙ step through use case, ❙ UI designer ❙ note the objects it requires ❙ Use case specifier ❙ note the operations it uses ❙ Use case engineer ❙ Component engineer ❚ Clean up the model CS361 7-3 CS361 7-4 Architect UI design ❚ Determine which use cases need to be ❚ Logical design developed first. ❙ Which user-interface elements are needed for ❚ High priority use cases each use case? ❙ describe important and critical functionality ❙ What information does the actor need to receive from or give to the system? ❘ security ❘ database ❚ Prototyping ❙ hard to retrofit later ❙ Often is on paper. ❙ Test on real users CS361 7-5 CS361 7-6 1 Requirements Specification Analysis model ❚ Not all requirements go in a use case. ❚ Class diagrams ❙ Example: security ❙ vague interfaces (“responsibilities”) ❙ Example: global performance ❙ vague associations (ignore navigability) ❚ Requirements document describes all ❙ stereotype classes: other requirements that are not suitable ❘ boundary - UI, associated with actor for use cases. ❘ control - control associated with a use case ❘ entity - persistent, the “real” objects ❚ Use-case realization (Analysis) CS361 7-7 CS361 7-8 Stereotypes Packages <<control>> Automatic claim processor <<boundary>> ❚ Logical grouping Mainframe system ❚ Used to +handle claim() +handle claim() ❙ divide large system into smaller subsystems 0..n ❙ show dependencies between subsystems <<entity>> <<boundary>> <<boundary>> Postal system ❚ Can contain Claim Adjudicator 0..n ❙ class diagrams or packages -field1 : any 0..1 +ID : string +send letter() ❙ use cases, sequence diagrams, etc. -field2 : any +handle claim() +accept/reject() CS361 7-9 CS361 7-10 Packages Packages and dependencies ❚ Reduce coupling (so that teams can work independently) «Facade» Claims processing system ❚ Increase cohesion ❚ In packages ❙ cohesion is between classes in a package ❙ coupling is between classes in different packages Image processing Claims Mainframe interface ❚ In classes ❙ cohesion is between methods in a class ❙ coupling is between methods in different classes CS361 7-11 CS361 7-12 2 Architect Architect ❚ Responsible for the integrity of analysis ❚ Identify common special requirements model ❙ Persistence ❙ Makes sure packages fit together ❙ Distribution and concurrency ❙ Makes sure each package is good ❙ Security ❙ Identifies obvious entity classes ❙ Fault tolerance ❙ Lets other classes be defined during use-case ❙ Transaction management realizations and component analysis CS361 7-13 CS361 7-14 Use case engineer Component Engineer ❚ Identify analysis classes needed by use- ❚ Analyze classes case ❙ Gather information from use cases ❘ Boundary classes, control classes, entity classes ❙ Make sure class is coherent ❚ Distribute behavior of use-case to classes ❙ Make model as simple as possible, but no ❚ Make use-case realization: a precise simpler. description of use-case ❚ Analyze a package ❙ sequence diagram ❙ Relationships between classes ❙ collaboration diagram ❙ Relationships between packages CS361 7-15 CS361 7-16 Outline of RUP process for analysis Object diagram ❚ Find use cases ❚ Snapshot of objects in a system at a point ❚ Architect determines order in time ❚ Repeatedly, ❚ If there is just one object of each class, ❙ take next use case the class diagram and the object diagram ❙ change class diagram to accommodate use are the same case ❚ As classes become more reusable, object ❙ simplify class diagram diagram becomes more interesting CS361 7-17 CS361 7-18 3 Class diagram Class and object diagrams <<control>> Automatic claim processor <<boundary>> Mainframe system 101:Claim +handle claim() Jim:Adjudicator +handle claim() 102:Claim 0..n Id:620194211 103:Claim <<entity>> <<boundary>> <<boundary>> Postal system :Claim Processor Claim Adjudicator 0..n Jane:Adjudicator 104:Claim -field1 : any 0..1 Id:301478334 +ID : string +send letter() 105:Claim -field2 : any +handle claim() +accept/reject() CS361 7-19 CS361 7-20 Summary Analysis/Design in XP ❚ Similar to RUP except that ❚ Analysis is converting vague user needs ❙ everyone does it into a precise model of what the system ❙ little written, more oral should do. ❙ less is done before writing code ❚ Analysis is incremental; look at one piece of the problem at a time. ❚ Requires continually changing the model until you are done. CS361 7-21 CS361 7-22 Modeling example in XP Why we model incrementally? ❚ Code is the model!! ❚ We can only think about one thing at a ❚ Build up model bit by bit time ❚ Look at one requirement at a time ❚ Criticism is easier than creation ❚ A new requirement might require ❚ As long as we get the right answer, it ❙ adding to model doesn’t matter how we got it ❙ changing model ❚ Model should support all the requirements you’ve seen so far CS361 7-23 CS361 7-24 4 Use Case Diagram for The The Viking Viking ❚ A direct marketing system generating letters ❚ Sends customized mail and e-mail sending letters mail system ❚ http://designfest.acm.org/Problems/ adding customer info Viking/Viking_00.pdf template creation ❚ Description consists of a set of use cases User delivery monitoring customer selection list information support CS361 7-25 CS361 7-26 Generating letters Viking A user selects a set of customers to whom selection Letter they wish to send letters and a template customers that defines the letter format. The Viking Customer Template then generates a letter per customer that letterFor() is based on filling in the “pluggable” information for the template with customer-related information. The user then previews the result of expanding the template list for each of the customers. CS361 7-27 CS361 7-28 Template Dear <<Proper Salutation>> <<Customer Name>> Viking * preview Letter customers Thank you very much from ordering from us on <<Date of * * most recent order>>. We recently received several Customer Template TemplateComponent thousand cans of the special ingredient, … letterFor() stringFor() If you are interested, please click on http:// Field Constant theHappyViking.com/SpecialOrder/<<special order name value number>>/Order.html stringFor() stringFor() stringFor(aCustomer) { return aCustomer.valueOf(name)} CS361 7-29 CS361 7-30 5 Use template to create a letter for a customer Viking * letter := empty letter; Letter customers for each component c of template, add * c.stringFor(customer) to letter Customer Template * TemplateComponent letterFor() * stringFor() If c is a constant, c.stringFor() is c.value. Property name valueOf() Field Constant name value If c is a field, c.stringFor(customer) is stringFor() stringFor() customer.valueOf(c.name) stringFor(aCustomer) { return aCustomer.valueOf(name)} CS361 7-31 CS361 7-32 Sending letters selection * A user chooses from among the generated Viking Letter letters and decides which ones to send out and by which MailingSystem to send them. * customers Customer The Viking should already have information MailingSystem * mail() associated with each customer so it can Property properly distribute the letter by a particular name MailingSystem; the user should not need to valueOf() PostalSystem SMTP enter this information as part of the mail() mail() sending process. CS361 7-33 CS361 7-34 Adding Customer Information Viking * MailingSystem A user knows of a new customer that she mail() selection wants to add to The Viking. The user can * customers * create a new customer entry and record Customer * Letter PostalSystem SMTP relevant information (Name, Salutation, * mail() mail() Property Address, Recent Purchase, and anything name needed by other parts of The Viking) for value A Customer has a property “e-mail address” that customer. and “postal address” which are used by the MailingSystems to obtain an address. CS361 7-35 CS361 7-36 6 Interface for creating customer Viking Create New Customer Name: Anna Kurn * customers Salutation: Ms. Customer Address: 712 Maple Ave, Toronto NY * E-mail: E-mail: akurn@fipster.com Property Recent purchase: Recent purchase: #e45 name value CS361 7-37 CS361 7-38 Template Creation A user creates a new template either from Viking scratch or by copying an existing template. A template needs to support * Template TemplateComponent both constant and “pluggable” letterFor() stringFor() information, and a user should be able to create a template and preview its Field Constant appearance. name value stringFor() stringFor() CS361 7-39 CS361 7-40 User interfaces Viking ❚ Generate letters (select a set of customers and a template) and preview them * Template Template TemplateComponent ❚ Select letters to send and the mailing Parser letterFor() stringFor() system to use ❚ Create new customer and enter info Field Constant name value ❚ Create new template and preview it stringFor() stringFor() CS361 7-41 CS361 7-42 7 Delivery Monitoring A user reviews the letters to see which have been sent and whether any of them have Viking * MailingSystem “failed delivery”. If so, the user can mail() choose to resend them
Recommended publications
  • Lecture for Chapter 2, Modeling With
    09/10/2019 Overview: modeling with UML Modeling with UML What is modeling? What is UML? Use case diagrams Class diagrams Oriented Software Engineering - Object What is modeling? Example: street map Modeling consists of building an abstraction of reality. Abstractions are simplifications because: They ignore irrelevant details and They only represent the relevant details. What is relevant or irrelevant depends on the purpose of the model. Why model software? Systems, Models and Views Why model software? A model is an abstraction describing a subset of a system A view depicts selected aspects of a model Software is getting increasingly more complex A notation is a set of graphical or textual rules for depicting views Windows XP > 40 million lines of code Views and models of a single system may overlap each other A single programmer cannot manage this amount of code in its entirety. Code is not easily understandable by developers who did not Examples: write it System: Aircraft We need simpler representations for complex systems Models: Flight simulator, scale model Modeling is a mean for dealing with complexity Views: All blueprints, electrical wiring, fuel system 1 09/10/2019 Systems, Models and Views Models, Views and Systems (UML) Flightsimulator Blueprints * * System Model View Aircraft Described by Depicted by Model 2 View 2 View 1 System Airplane: System View 3 Model 1 Scale Model: Model Flight Simulator: Model Electrical Wiring Scale Model Blueprints: View Fuel System: View Electrical Wiring: View What is UML? What is UML? UML (Unified Modeling Language) The Unified Modeling Language (UML) is a language for Specifying An emerging standard for modeling object-oriented software.
    [Show full text]
  • The Guide to Succeeding with Use Cases
    USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0? 4 First Principles 5 Principle 1: Keep it simple by telling stories 5 Principle 2: Understand the big picture 5 Principle 3: Focus on value 7 Principle 4: Build the system in slices 8 Principle 5: Deliver the system in increments 10 Principle 6: Adapt to meet the team’s needs 11 Use-Case 2.0 Content 13 Things to Work With 13 Work Products 18 Things to do 23 Using Use-Case 2.0 30 Use-Case 2.0: Applicable for all types of system 30 Use-Case 2.0: Handling all types of requirement 31 Use-Case 2.0: Applicable for all development approaches 31 Use-Case 2.0: Scaling to meet your needs – scaling in, scaling out and scaling up 39 Conclusion 40 Appendix 1: Work Products 41 Supporting Information 42 Test Case 44 Use-Case Model 46 Use-Case Narrative 47 Use-Case Realization 49 Glossary of Terms 51 Acknowledgements 52 General 52 People 52 Bibliography 53 About the Authors 54 USE-CASE 2.0 The Definitive Guide Page 2 © 2005-2011 IvAr JacobSon InternationAl SA. All rights reserved. About this Guide This guide describes how to apply use cases in an agile and scalable fashion. It builds on the current state of the art to present an evolution of the use-case technique that we call Use-Case 2.0.
    [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]
  • Lab 002 – Use Case Modeling.Pdf
    TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia LAB 2: Introduction to Use Case Modeling OBJECTIVES Familiarize with the concept underlining Use Case Diagram for requirement analysis. Exposure on all elements grouped under UML Case Diagram. Analyze functional requirements and problem statements of an intended system to be able to translate into use case modeling. Be able to document use case description and specifications. INTRODUCTION Definition of Use Case Diagram A Use Case is a set of scenarios describing an interaction between a user and a system. Use Case diagram displays (in symbolic form) the relationship among actor and use cases. Use case represents the system’s functionality, the requirements of the system from the user’s perspective. When to use Use Cases Use cases are used in almost every project. Very helpful in exposing requirements and planning of project. Usually done during the early stages of project. Frequently starts by being loose in terms of connection and accuracy, but as project continues, the use cases are defined better. UML Notation for Use Case Modeling Construct Description Syntax Use Case A description of a set of sequences of actions, including variants, that system performs that yields an observable value to an actor (Booch, 1993). Actor The people or system that provides or receives information from the system; called the stakeholder of the system. Nor Samsiah Binti Sani 1 TU2943: Information Engineering Methodology Lab Notes, 2009-2010, Faculty of Technology and Information Science, Universiti Kebangsaan Malaysia System The boundary between the physical system and Boundary the actors who interact with the physical system.
    [Show full text]
  • Writing Use Case Scenarios for Model Driven Development
    Enterprise Architect Writing Use Case Scenarios for Model Driven Development Series: Quick Start Guide http://www.sparxsystems.com Writing Use Case Scenarios for Model Driven Development This guide outlines how to use Enterprise Architect to rapidly build Use Cases and increase your productivity through Model Driven Development. Use Case Scenarios can help drive downstream development via automatically generated test cases, activity diagrams, sequence diagrams and much more. In this guide, we use an example Automatic Teller Machine (ATM) system to explain Enterprise Architect's Structured Scenario editing capability. All material © Sparx Systems 2010 http://www.sparxsystems.com ©Sparx Systems 2010 Page 1 Enterprise Architect Writing Use Case Scenarios for Model Driven Development Series: Quick Start Guide http://www.sparxsystems.com Table of Contents Introduction.................................................................................................................................3 What You Will Learn..................................................................................................................3 What You Will Gain....................................................................................................................3 Assumptions................................................................................................................................3 Glossary......................................................................................................................................4
    [Show full text]
  • Fakulta Informatiky UML Modeling Tools for Blind People Bakalářská
    Masarykova univerzita Fakulta informatiky UML modeling tools for blind people Bakalářská práce Lukáš Tyrychtr 2017 MASARYKOVA UNIVERZITA Fakulta informatiky ZADÁNÍ BAKALÁŘSKÉ PRÁCE Student: Lukáš Tyrychtr Program: Aplikovaná informatika Obor: Aplikovaná informatika Specializace: Bez specializace Garant oboru: prof. RNDr. Jiří Barnat, Ph.D. Vedoucí práce: Mgr. Dalibor Toth Katedra: Katedra počítačových systémů a komunikací Název práce: Nástroje pro UML modelování pro nevidomé Název práce anglicky: UML modeling tools for blind people Zadání: The thesis will focus on software engineering modeling tools for blind people, mainly at com•monly used models -UML and ERD (Plant UML, bachelor thesis of Bc. Mikulášek -Models of Structured Analysis for Blind Persons -2009). Student will evaluate identified tools and he will also try to contact another similar centers which cooperate in this domain (e.g. Karlsruhe Institute of Technology, Tsukuba University of Technology). The thesis will also contain Plant UML tool outputs evaluation in three categories -students of Software engineering at Faculty of Informatics, MU, Brno; lecturers of the same course; person without UML knowledge (e.g. customer) The thesis will contain short summary (2 standardized pages) of results in English (in case it will not be written in English). Literatura: ARLOW, Jim a Ila NEUSTADT. UML a unifikovaný proces vývoje aplikací : průvodce ana­lýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, 2003. xiii, 387. ISBN 807226947X. FOWLER, Martin a Kendall SCOTT. UML distilled : a brief guide to the standard object mode•ling language. 2nd ed. Boston: Addison-Wesley, 2000. xix, 186 s. ISBN 0-201-65783-X. Zadání bylo schváleno prostřednictvím IS MU. Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně.
    [Show full text]
  • The Unified Modeling Language Reference Manual
    The Unified Modeling Language Reference Manual The Unified Modeling Language Reference Manual James Rumbaugh Ivar Jacobson Grady Booch ADDISON-WESLEY An imprint of Addison Wesley Longman, Inc. Reading, Massachusetts • Harlow, England • Menlo Park, California Berkeley, California • Don Mills, Ontario • Sydney Bonn • Amsterdam • Tokyo • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial caps or all caps. Unified Modeling Language, UML, and the UML cube logo are trademarks of the Object Management Group. Some material in this book is derived from the Object Management Group UML Specification documentation. Used by permission of the Object Management Group. The authors and publisher have taken care in the preparation of this book but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers discounts on this book when ordered in quantity for special sales. For more information, please contact: AWL Direct Sales Addison Wesley Longman, Inc. One Jacob Way Reading, Massachusetts 01867 (781) 944-3700 Visit AW on the Web: www.awl.com/cseng/ Library of Congress Cataloging-in-Publication Data Rumbaugh, James. The unified modeling language reference manual / James Rumbaugh, Ivar Jacobson, Grady Booch. p. cm. — (The Addison-Wesley object technology series) Includes bibliographical references and index.
    [Show full text]
  • The IBM Rational Unified Process for System Z
    Front cover The IBM Rational Unified Process for System z RUP for System z includes a succinct end-to-end process for z practitioners RUP for System z includes many examples of various deliverables RUP for System z is available as an RMC/RUP plug-in Cécile Péraire Mike Edwards Angelo Fernandes Enrico Mancin Kathy Carroll ibm.com/redbooks International Technical Support Organization The IBM Rational Unified Process for System z July 2007 SG24-7362-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (July 2007) This edition applies to the IBM Rational Method Composer Version 7.1 © Copyright International Business Machines Corporation 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this IBM Redbooks publication . .x Become a published author . xii Comments welcome. xii Part 1. Introduction to the IBM Rational Unified Process for System z. 1 Chapter 1. Introduction. 3 1.1 Purpose. 4 1.2 Audience . 4 1.3 Rationale . 4 1.4 Scope . 5 1.5 Overview . 5 Part 2. The IBM Rational Unified Process for System z for Beginners . 9 Chapter 2. Introduction to the IBM Rational Unified Process and its extension to Service-Oriented Architecture. 11 2.1 Overview . 12 2.2 Introduction to RUP. 13 2.2.1 The heart of RUP . 13 2.2.2 The IBM Rational Method Composer (RMC) platform . 13 2.3 Key principles for successful software development.
    [Show full text]
  • Reference Manual for Astah Professional And
    Astah Reference Manual Ver. 8.4 Astah professional Astah UML Copyright© 2006-2021 Change Vision, Inc. All rights reserved. Astah Reference Manual The contents of this manual may be changed without prior notice. The following trademarks and copyright apply to the software that is provided with this manual. Copyright© 2006-2021 Change Vision, Inc. All rights reserved. UML and Unified Modeling Language are either registered trademarks or trademarks of Object Management Group, Inc. in the United States and/or other countries. Java is registered trademarks of Oracle and/or its affiliates. Mind Map is a registered trademark of the Buzan Organization Ltd. If other trademarked product names or company names appear, they are only used as names. Symbols, such as ™, ®, ©, are omitted in the main contents. Astah Reference Manual Introduction This Manual, “Astah Reference Manual”, briefly explains the functions of Astah and how to use them. Astah Professional is a system design tool that supports UML (Unified Modeling Language) 2.x (partly), UML1.4, Flowchart, Data Flow Diagram, ER diagram, CRUD, Requirement diagram and Mind Map. Astah UML is a modeling tool that supports UML (Unified Modeling Language) 2.x (partly), UML1.4 and Mind Map. Structure of this Manual · Chapter 1-3 Overview of Astah and getting started · Chapter 4-6 Basic Astah concepts and Main Menu functions · Chapter 7-13 Basic diagram and model operations · Chapter14 Specific diagram and diagram element operations · Chapter15-46 System set-up and specific Astah features Note · Functions with [P] are supported in Astah Professional only. These are not included in Astah UML.
    [Show full text]
  • Use Case Diagrams
    Purpose of Use Case Diagrams Document the functionality of the system from the users’ perspective Use Case Diagrams Document the scope of the system Document the interaction between the users and the system using supporting use case descriptions Lecture 3B (behaviour specifications) U08182 © Peter Lo 2010 1 U08182 © Peter Lo 2010 2 1 2 Use Case Modeling Dependencies A Use Case represents the steps in a specific business function or process. An external entity, called an Actor, initiates a use case by requesting the system to perform a function or process. U08182 © Peter Lo 2010 3 U08182 © Peter Lo 2010 4 Actors Use Case diagram showing both «include» and «extend» •Drawn as stick people with a name •Extend and Include relationships between use cases •The roles that people, other systems or devices take when communicating with a •Shown as stereotyped dependencies particular use case or use cases •Stereotypes are written as text strings in guillemets: «extend» and «include» •Not the same as job titles or people •People with one job title may play the roles of several actors •One actor may represent several job titles Use Cases •Drawn as ellipses with a name in or below each ellipse •Describe a sequence of actions that the system performs to achieve an observable result of value to an actor •The name is usually an active verb and a noun phrase Communication Associations •Line drawn between an actor and a use case •Can have arrow heads to show where the communication is initiated (arrow points away from the initiator) •Represent communication
    [Show full text]
  • Important Java Programming Concepts
    Appendix A Important Java Programming Concepts This appendix provides a brief orientation through the concepts of object-oriented programming in Java that are critical for understanding the material in this book and that are not specifically introduced as part of the main content. It is not intended as a general Java programming primer, but rather as a refresher and orientation through the features of the language that play a major role in the design of software in Java. If necessary, this overview should be complemented by an introductory book on Java programming, or on the relevant sections in the Java Tutorial [10]. A.1 Variables and Types Variables store values. In Java, variables are typed and the type of the variable must be declared before the name of the variable. Java distinguishes between two major categories of types: primitive types and reference types. Primitive types are used to represent numbers and Boolean values. Variables of a primitive type store the actual data that represents the value. When the content of a variable of a primitive type is assigned to another variable, a copy of the data stored in the initial variable is created and stored in the destination variable. For example: int original = 10; int copy = original; In this case variable original of the primitive type int (short for “integer”) is assigned the integer literal value 10. In the second assignment, a copy of the value 10 is used to initialize the new variable copy. Reference types represent more complex arrangements of data as defined by classes (see Section A.2).
    [Show full text]
  • Top-Down Software Decomposition – an Approach for Component-Based Design Automation
    Top-down Software Decomposition – An Approach for Component-based Design Automation Whitepaper Ionut Cardei Department of Computer Science and Engineering Florida Atlantic University Boca Raton, FL 33431 07/21/2006 Abstract In this whitepaper we summarize the objectives and the technical approach of the Top- down Software Decomposition project and we describe a methodology for improving the quality and reducing the costs of the design process. In our approach product requirements and component semantics are conceptualized in ontologies, providing semantic descrip- tions that are machine readable and can be processed for consistency checking and model synthesis through a process that involves machine reasoning. This paper also provides a brief summary the main technologies involved in this project. The Model Driven Architecture provides the backdrop for a formal software development process and for visual modeling tools. We describe the UML and SysML modeling tools that are commonly used in the industry for requirements analysis and for software design. The main technologies from the semantic web research domain are covered, such as RDF, RDFS, OWL and reasoning engines. 1 Introduction This project has focus on improving the architecture design quality, increasing productivity and reducing the cost of the development process. In this whitepaper we present our approach for automating component-based design through top-down decomposition and we introduce several supporting technologies and tools. We begin by describing the problem we address and the motivation behind our project. As part of the system development cycle, a development iteration begins with requirements spec- ification, where marketing specialists and product managers describe functional requirements, technical specifications, features and use cases in natural language, in a semi-formal format, such as MRDs, UML or SysML, or using requirements management tools such as DOORS 1 [23] or RequisitePro [21].
    [Show full text]