DOCSLIB.ORG

Secure Resource Sharing System

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Secure Resource Sharing System DEGREE PROJECT, IN TIDAB , FIRST LEVEL STOCKHOLM, SWEDEN 2015 SecuRES: Secure Resource Sharing System AN INVESTIGATION INTO USE OF PUBLIC LEDGER TECHNOLOGY TO CREATE DECENTRALIZED DIGITAL RESOURCE-SHARING SYSTEMS DANIEL SVENSSON AND PHILIP LEUNG KTH ROYAL INSTITUTE OF TECHNOLOGY ICT TRITA TRITA-ICT-EX-2015:157 www.kth.se Abstract The project aims at solving the problem of non-repudiation, integrity and confidentiality of data when digitally exchanging sensitive resources between parties that need to be able to trust each other without the need for a trusted third party. This is done in the framework of answering to what extent digital resources can be shared securely in a decentralized public ledger-based system compared to trust-based alternatives. A background of existing resource sharing solutions is explored which shows an abundance third party trust-based systems, but also an inter- est in public ledger solutions in the form of the Storj network which uses such technology, but focuses on storage rather than sharing. The proposed solution, called SecuRES, is a communication protocol based on public ledger technology which acts similar to Bitcoin. A prototype based on the protocol has been implemented which proves the ability to share encrypted files with one or several recipients through a decentral- ized public ledger-based network. It was concluded that the SecuRES solution could do away with the requirement of trust in third parties for all but some optional op- erations using external authentication services. This is done while still maintaining data integrity of a similar or greater degree to trust-based solutions and offers the additional benefits of non-repudiation, high con- fidentiality and high transparency from the ability to make source code and protocol documentation openly available without endangering the system. Further research is needed to investigate whether the system can scale up for widespread adoption while maintaining security and rea- sonable performance requirements. Keywords Public ledger, Blockchain, Bitcoin, Non-repudiation, Trust, Secure trans- actions, Resource sharing, Decentralisation, Elliptic curve cryptography, Integrity, Confidentiality. Abstract Projektet ämnar lösa problemen med oförnekbarhet, integritet och kon- fidentialitet när man delar känsligt data mellan parter som behöver lita på varandra utan inblanding av betrodd tredje part. Detta diskuteras för att besvara till vilken omfattning digitala resurser kan delas säk- ert i ett decentraliserat system baserat på publika liggare jämfört med existerande tillitsbaserade alternativ. En undersökning av nuvarande resursdelningslösningar visar att det existerar många tillitsbaserade system men även en växande andel lös- ningar baserade på publika liggare. En intressant lösning som lyfts fram är Storj som använder sådan teknologi men fokuserar på resurslagring mer är delning. Projektets föreslagna lösning, kallad SecuRES, är ett kommunika- tionsprotokoll baserat på en publik liggare likt Bitcoin. En prototyp baserad på protokollet har tagits fram som visar att det är möjligt att dela krypterade filer med en eller flera mottagare genom ett decentralis- erat nätverk baserat på publika liggare. Slutsatsen som dras är att SecuRES klarar sig utan betrodda tredje parter för att dela resurser medan vissa operationer kan göras mer användarvänliga genom externa autentiseringstjänster. Själva lösnin- gen garanterar integritet av data och medför ytterligare fördelar såsom oförnekbarhet, konfidentialitet och hög transparens då man kan göra källkoden och protocoldokumentation fritt läsbar utan att utsätta sys- temet för fara. Vidare forskning behövs för att undersöka om systemet kan skalas upp för allmän användning och alltjämt bibehålla säkerhets- samt pre- standakrav. Nyckelord Publik liggare, Blockkedja, Bitcoin, Oförnekbarhet, Tillit, Säkra transak- tioner, Resursdelning, Decentralisering, Elliptic curve cryptografi, In- tegritet, Konfidentialitet. Glossary Bitcoin A collective term for the entire network, currency and technology behind it.. 12 bitcoin The denomination of the currency. bitcoins can be further divided into millibitcoins etcetera down to the smallest denomination which is a satoshi. 11, 12, 50 block A collection of transactions. Part of the blockchain which constitutes the public ledger containing all the verified transactions in the network. 12 blockchain The public ledger that contains all the verified transactions in the network.. 12 business logic The model of a system where calculations and manipulation of data occurs. 39, 40 confidentiality Confidentiality means that only those that are supposed to be able to read something are able to do so. 31 DAO Database Access Object. 67 DMZ De-militarized zone. 27 DTO Data Transfer Object, A data container without logic. 44, 67 ECC Elliptic Curve Cryptography. 13, 32, 33, 68 Git A distributed version control system. 47 GUI Graphical User Interface. 69 IDS Intrusion Detection System. 27 JPA Java Persistence API. 44, 45, 67 JUnit Testing framework for Java. 44 JVM Java Virtual Machine, the virtual machine constituting the environment wherein java code execute. 44 LATEX Typesetting system. 47 markdown Markup language for typesetting text with the possibility to export to many different formats. 47 MySQL Popular relational database. 68 non-functional requirements Requirements that describe not what feature to implement but rather how it should perform. 46 OpenPGP Encryption standard for email. 28 P2P Peer-To-Peer. 17 POM Project Object Model. 45 public interface The accessors controlling access to entities within a class. Enti- ties prefixed by modifiers such as public and protected are part of this interface. 39 RIPEMD160 RACE Integrity Primitives Evaluation Message Digest which pro- duce 160-bit output. 34 RSA Public-key encryption algorithm. 32, 33, 66–68 Scrum Iterative agile software development methodology. 8, 45, 46 secp256k1 Standard defining a specific elliptic curve and mathematical constants. 32, 33 SecuRES Secure Resource sharing protocol. 8, 49–56, 66–68, 71–73, 76–79 SHA256 Secure Hashing Algorithm that produce 256-bit output. 19, 21, 34 SPV Simple Payment Verification. Does not depend on the entire blockchain. 17, 18, 23, 65, 78 UML Unified Modeling Language. 41 UTXO Unspent Transaction Output. 15–18 Preface The authors would like to thank: • Sead Muftic, our examiner, for giving us this opportunity • Nazri Abdullah for acting as discussion partner for our designs • Christian Gotare, our corporate supervisor, for his experienced insights • Anders Sjögren, our head of programme, for always taking the time to answer our questions • Our loved ones for their patience with us while we were absent during this project Contents 1 Introduction 1 1.1 Background . 1 1.1.1 Sharing a sensitive Contract . 1 1.1.2 Secure Email . 2 1.1.3 Cloud Storage . 2 1.1.4 Public Ledgers . 2 1.2 Problem . 2 1.3 Purpose . 4 1.4 Goal . 5 1.4.1 Expected Deliverables . 5 1.4.2 Benefits . 6 1.4.3 Ethics . 6 1.4.4 Sustainability . 7 1.5 Methodology Overview . 7 1.5.1 Feasibility Phase . 7 1.5.2 Design and Implementation Phases . 7 1.6 Delimitations . 8 1.7 Outline . 8 1.8 Contributions . 9 2 Theoretical Background 11 2.1 Bitcoin . 11 2.1.1 Overview, [1, p.1-2] . 11 2.1.2 Transactions . 13 2.1.3 Decentralized Peer-To-Peer Network . 17 2.1.4 The Blockchain . 19 2.1.5 Alternative Chains, Currencies and Applications . 22 2.1.6 Conclusion . 23 2.2 Storj . 24 2.2.1 Storage . 24 2.2.2 Heartbeats . 24 2.2.3 Implementation . 24 2.2.4 Sharing . 25 2.2.5 Ownership Verification . 25 2.2.6 Conclusion . 25 2.3 Dropbox . 25 2.3.1 Product Features . 25 2.3.2 Architecture . 26 2.3.3 Reliability . 26 2.3.4 Security . 27 2.3.5 Conclusion . 27 2.4 Secure Email . 28 2.4.1 Confidentiality . 28 2.4.2 Authentication . 29 2.4.3 Conclusion . 29 2.5 Git . 29 2.5.1 Snapshots . 29 2.5.2 Branching . 30 2.5.3 Conclusion . 30 2.6 Cryptography . 30 2.6.1 Symmetric Cryptography . 31 2.6.2 Asymmetric Cryptography . 31 2.6.3 Hashing . 33 2.6.4 Digital Signatures . 34 2.6.5 Public-Key Certificates . 34 2.6.6 Digital Envelopes . 34 2.6.7 Conclusion . 35 2.7 Summary . 35 3 Methodology 37 3.1 Literature Study . 37 3.2 Development . 38 3.2.1 Analysis . 38 3.2.2 Design . 38 3.2.3 Coding . 42 3.2.4 Implementation . 44 3.2.5 Development Methodology . 45 3.3 Project management . 46 3.3.1 Project . 46 3.3.2 Documentation . 47 3.3.3 Collaboration . 47 4 Solution 49 4.1 Requirements . 49 4.1.1 Functional Requirements . 49 4.1.2 Security Requirements . 50 4.2 Network . 50 4.3 Concepts . 50 4.3.1 Sharing a File . 50 4.3.2 Confidentiality and Integrity . 51 4.3.3 File Slice . 51 4.3.4 File Crumb . 51 4.3.5 Updating a File . 51 4.3.6 File Management . 52 4.3.7 Slice Verification . 52 4.3.8 Access Permissions . 53 4.3.9 Branching . 53 4.3.10 Splitting . 53 4.3.11 Joining . 54 4.3.12 Double Spending . 54 4.3.13 Transaction Verification . 54 4.3.14 Transactions . ..
Load more

Recommended publications
  • Guidelines for UML Or Sysml Modelling Within an Enterprise Architecture
    Guidelines for UML or SysML modelling within an enterprise architecture Mälardalen University Academy of Innovation, Design and Technology Author: Charlie Höglund Email: [email protected] Bachelor of Science in Computer Science/Basic level, 15hp Date: 2017-06-08 Examiner: Jan Carlson Supervisor: Daniel Sundmark Company supervisor: Fredric Andréasson (Volvo Construction Equipment) Abstract Enterprise Architectures (EA) are used to describe an enterprise’s structure in a standardized way. An Enterprise Architecture also provides decision-support when choosing a direction or making changes at different levels of an enterprise, such as the business architecture or technology architecture level. This can involve decisions such as: What kind of enterprise should this be, what kind of technologies should be used for new system developments etcetera. Therefore, using the Unified Modelling Language (UML) or Systems Modelling Language (SysML) together with standardized guidelines that help you decide what to do before, during, and after modelling could be important for producing correct and useful system models, which later on will be used to develop actual systems. At the moment, standardized guidelines of this kind do not really exist. However, there are a lot of information about why you should use UML or SysML, what kinds of UML or SysML diagrams that exist, or what notations to follow when creating a specific UML or SysML diagram. In this thesis, the objective has been to research about the usefulness and creation of standardized guidelines for UML or SysML modelling in an Enterprise Architecture (i.e. mainly intended for the automotive industry domain). For this reason, the two research questions: “how can you create useful standardized guidelines for UML or SysML modelling?” and “what do useful standardized guidelines for UML or SysML modelling look like?” were chosen.
    [Show full text]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007
    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
    [Show full text]
  • AP42 Section: Reference
    AP42 Section: 13.2.1 Reference: 8 Title: Paved Road Particulate Emissions, C. Cowherd, Jr., and P. J. Englehart, EPA-600/7-84-077, U. S. Environmental Protection Agency, Cincinnati, OH, July 1984. United Slates EPA-600 17- 84-077 Environmental Protection Agency July 1984 PAVED ROADS eEPA Research and Ap-42 Section 11.2.51\ Reference Number Development 4 iI J PAVED ROAD PARTICULATE EMISSIONS Source Category Report Prepared for Office of Air Quality Planning and Standards Prepared by Industrial Environmental Research Laboratory Research Triangle Park NC 2771 1 RESEARCH REPORTING SERIES Research reports of the Office of Research and Development, US. Environmental Protection Agency, have been grouped into nine series. These nine broad cate- gories were established to facilitate further development and application of en- vironmental technology. Elimination of traditional grouping was consciously planned to foster technology transfer and a maximum interface in related fields. The nine series are: 1. Environmental Health Effects Research 2. Environmental Protection Technology 3. Ecological Research 4. Environmental Monitoring .. 5. Socioeconomic Environmental Studies 6. Scientific and Technical Assessment Reports (STAR) 7. Interagency Energy-Environment Research and Development 8. “Special” Reports 9. Miscellaneous Reports This report has been assigned to the INTERAGENCY ENERGY-ENVIRONMENT RESEARCH AND DEVELOPMENT series. Reports in this series result from the effort funded under the 17-agency Federal Energy/Environment Research and Development Program. These studies relate to EPA’s mission to protect the public health and welfare from adverse effects of pollutants associated with energy sys- tems. The goal of the Program is to assure the rapid development of domestic energy supplies in an environmentally-compatible manner by providing the nec- essary environmental data and control technology.
    [Show full text]
  • 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]
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial
    OMG Systems Modeling Language (OMG SysML™) Tutorial 11 July 2006 Sanford Friedenthal Alan Moore Rick Steiner Copyright © 2006 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Caveat • This material is based on version 1.0 of the SysML specification (ad-06-03-01) – Adopted by OMG in May ’06 – Going through finalization process • OMG SysML Website – http://www.omgsysml.org/ 11 July 2006 Copyright © 2006 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should understand the: • Benefits of model driven approaches to systems engineering • Types of SysML diagrams and their basic constructs • Cross-cutting principles for relating elements across diagrams • Relationship between SysML and other Standards • High-level process 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 – Already familiar with system modeling & tools, or – Want to learn about systems modeling • Software Engineers who want to express systems concepts • Familiarity with UML is not required, but it will help 11 July 2006 Copyright © 2006 by Object Management Group. 3 Topics • Motivation & Background (30) • Diagram Overview (135) • SysML Modeling as Part of SE Process (120) – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework (20) • Transitioning to SysML (10) • Summary (15) 11 July 2006 Copyright © 2006 by Object Management Group. 4 Motivation & Background SE Practices for Describing Systems Future Past • Specifications • Interface requirements • System design • Analysis & Trade-off • Test plans Moving from Document centric to Model centric 11 July 2006 Copyright © 2006 by Object Management Group.
    [Show full text]
  • Examples of UML Diagrams
    UML Diagrams Examples Examples by Technology or Application Domain Online shopping UML diagrams Ticket vending machine UML diagrams Bank ATM UML diagrams Hospital management UML diagrams Digital imaging and communications in medicine (DICOM) UML diagrams Java technology UML diagrams Application development for Android UML diagrams Software licensing and protection using SafeNet Sentinel HASP security solution Examples by Types of Diagrams Activity diagram examples Class diagram examples Communication diagram examples Component diagram examples Composite structure diagram examples Deployment diagram examples Information flow diagram example Interaction overview diagram examples Object diagram example Package diagram examples Profile diagram examples http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 1 of 33 Sequence diagram examples State machine diagram examples Timing diagram examples Use case diagram examples Use Case Diagrams Business Use Case Diagrams Airport check-in and security screening business model Restaurant business model System Use Case Diagrams Ticket vending machine http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 2 of 33 Bank ATM UML use case diagrams examples Point of Sales (POS) terminal e-Library online public access catalog (OPAC) http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 3 of 33 Online shopping use case diagrams Credit card processing system Website administration http://www.uml-diagrams.org/index-examples.html 1/15/17, 1034 AM Page 4 of 33 Hospital
    [Show full text]
  • Part I Environmental Diagrams
    Adaptive Software Engineering G22.3033-007 Session 3 – Sub-Topic Presentation 1 Use Case Modeling Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences 1 Part I Environmental Diagrams 2 1 What it is • Environmental Diagram Rent Video Video Store Pay Information System Employees Clerk Customer Payroll Clerk 3 What it is • A picture containing all the important players (Actors) • Includes players both inside and outside of the system • Actors are a critical component • External events are a second critical component 4 2 Creating the Diagram • To create an environmental diagram • 1. Identify all the initiating actors • 2. Identify all the related external events associated with each actor 5 Why it is used • A diagram is needed to show the context or scope of the proposed system • At this time actors and external events are the critical components • It is helpful to include all the participants as well 6 3 Creating the Diagram • 3. Identify all the participating Actors • These actors may be inside (internal) or outside (external) to the system 7 Creating the Diagram • Examples of an internal actor – Clerk who enters the purchase into a Point of Sale terminal – Clerk who places paper in the printer – Accountant who audits report 8 4 Creating the Diagram • Examples of an external actor – Accountant who audits report – A credit authorizing service – A DMV check for renting a car 9 Creating the Diagram •4.Draw a cloud • 5. Then draw initiating actors on the left of the cloud • 6. Then draw participating external actors outside the cloud • 7.
    [Show full text]
  • TAGDUR: a Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems
    TAGDUR: A Tool for Producing UML Sequence, Deployment, and Component Diagrams Through Reengineering of Legacy Systems Richard Millham, Jianjun Pu, Hongji Yang De Montfort University, England [email protected] & [email protected] Abstract: A further introduction of TAGDUR, a documents this transformed system through a reengineering tool that first transforms a series of UML diagrams. This paper focuses on procedural legacy system into an object-oriented, TAGDUR’s generation of sequence, deployment, event-driven system and then models and and component diagrams. Keywords: UML (Unified Modeling Language), Reengineering, WSL This paper is a second installment in a series [4] accommodate a multi-tiered, Web-based that introduces TAGDUR (Transformation and platform. In order to accommodate this Automatic Generation of Documentation in remodeled platform, the original sequential- UML through Reengineering). TAGDUR is a driven, procedurally structured legacy system reengineering tool that transforms a legacy must be transformed to an object-oriented, event- system’s outmoded architecture to a more driven system. Object orientation, because it modern one and then represents this transformed encapsulates variables and procedures into system through a series of UML (Unified modules, is well suited to this new Web Modeling Language) diagrams in order to architecture where pieces of software must be overcome a legacy system’s frequent lack of encapsulated into component modules with documentation. The architectural transformation clearly defined interfaces. A transfer to a Web- is from the legacy system’s original based architecture requires a real-time, event- procedurally-structured to an object-oriented, driven response rather than the legacy system’s event-driven architecture.
    [Show full text]
  • Working with Deployment Diagram
    UNIVERSITY OF ENGINEERING AND TECHNOLOGY, TAXILA FACULTY OF TELECOMMUNICATION AND INFORMATION ENGINEERING SOFTWARE ENGINEERING DEPARTMENT Lab # 09 Working with Deployment Diagram You’ll learn in this Lab: What a deployment diagram is Applying deployment diagrams Deployment diagrams in the big picture of the UML A solid blueprint for setting up the hardware is essential to system design. The UML provides you with symbols for creating a clear picture of how the final hardware setup should look, along with the items that reside on the hardware What is a Deployment Diagram? A deployment diagram shows how artifacts are deployed on system hardware, and how the pieces of hardware connect to one another. The main hardware item is a node, a generic name for a computing resource. A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI). In UML 2.0 a cube represents a node (as was the case in UML 1.x). You supply a name for the node, and you can add the keyword «Device», although it's usually not necessary. Software Design and Architecture 4th Semester-SE UET Taxila Figure1. Representing a node in the UML A Node is either a hardware or software element. It is shown as a three-dimensional box shape, as shown below.
    [Show full text]
  • CSC2125: Modeling Methods, Tools and Techniques Winter 2018
    CSC2125: Modeling Methods, Tools and Techniques Winter 2018 Marsha Chechik Department of Computer Science University of Toronto Software Models http://www.cs.toronto.edu/~chechik/courses18/csc2125 csc2125. Winter 2018, Lecture 2b 1 Plan for the rest of the lecture • Part 0. Modeling • Part 1. Software Models, UML, OCL • Part 2. Meta-modeling, model mappings, DSLs / generic languages, model transformations • Part 3 (if we have time). How usable are models? csc2125. Winter 2018, Lecture 2b 2 csc2125. Winter 2018, Lecture 2b 3 What is Being Modelled? <postal-address> ::= <name-part> <street-address> <zip-part> <name-part> ::= <personal-part> <last-name> <opt-jr-part> <EOL> | <personal-part> <name-part> E = a KLOCb csc2125. Winter 2018, Lecture 2b 4 Models as Views Mason's Carpenter's View Architect's View View Electrician's View Tax Collector's Plumber's View View Landlord's Interior / Tenant's Designer's View View Zoning Law Interior View Designer's View Every view • obtained by a different projection, abstraction, translation • may be expressed in a different notation (modelling language) • reflects a different intent csc2125. Winter 2018, Lecture 2b 5 Modelling Paradigms Fundamental modelling paradigms, each emphasizing some basic view of the software to be developed. Structure Data System Functionality Schema Functionality Software Architecture Use Cases Deployment Algorithms Scenarios Constraints Constraints System System Behaviour Interactions Behaviour csc2125. Winter 2018, Lecture 2b 6 Entity-Relationship Diagrams An ER diagram is a structural model representing a software system's data elements and relationships among them. relationship entity attribute title course enrolled student name course no. id • originally invented for model database design (Chen, 1976) • emphasizes concepts/data • relationships can represent associations, navigability, containment, dependencies, etc.
    [Show full text]
  • Tutorial Exercise 4 Answer
    Information System Design (U08182) Tutorial Exercise 4 Answer 1. List the different categories of software that may be used in developing a system. CASE tools; compilers, interpreters and run-time support; visual editors; integrated development environments; class browsers; component managers; DBMS; CORBA; testing tools; conversion tools; documentation generators; configuration management systems; debuggers. 2. What packages (not the UML package concept) have you used and what categories do they fall into? The answer to this will depend on the individual. Examples would be: Rational Rose – CASE tool; Java – compiler with run-time support; JBuilder – visual editor/IDE; Microsoft Developer’s Studio – IDE; Oracle – DBMS; VisiBroker – CORBA ORB; TestScope – testing tool; ClearCase – configuration mangement tool; gdb – debugger. 3. Define what is meant by a component. A physical element of a system, usually a file of some sort. can be a source file, used in producing the software for the system, or an element of the runtime system 4. Define what is meant by a node. Processor in the implementation of a system, shown in a deployment diagram. 5. What is a notation for a component? U08182 @Peter Lo 2010 1 6. What is a notation for a node? 7. What are the main purposes of using component diagrams? Model physical software components and the relationships between them; Model source code and relationships between files; Model the structure of releases of software; Specify the files that are compiled into an executable. 8. What are the main purposes of using deployment diagrams? Model physical hardware elements and the communication paths between them; Plan the architecture of the system; Document the deployment of software components on hardware nodes.
    [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]