DOCSLIB.ORG

Security Pattern Validation and Recognition

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Security Pattern Validation and Recognition Security-Pattern Recognition and Validation Dissertation Submitted by Michaela Bunke on 12th December 2018 to the Universit¨atBremen Faculty of Mathematics and Computer Science in partial fulfillment of the requirements for the degree of Doktor der Ingenieurwissenschaften { Dr.-Ing. { Reviewed by Prof. Dr. Hans-J¨orgKreowski Universit¨atBremen, Germany and Dr. Karsten Sohr Universit¨atBremen, Germany In Memorial of Ilse Schlamilch Karl Schlamilch Manfred Friedrichs 21 November 1924 03 March 1927 29 August 1935 09 June 2017 19 June 2018 3 July 2017 ABSTRACT The increasing and diverse number of technologies that are connected to the Internet, such as distributed enterprise systems or small electronic devices like smartphones, brings the topic IT security to the foreground. We interact daily with these technologies and spend much trust on a well-established software development process. However, security vulnerabilities appear in software on all kinds of PC(- like) platforms, and more and more vulnerabilities are published, which compromise systems and their users. Thus, software has also to be modified due to changing requirements, bugs, and security flaws and software engineers must more and more face security issues during the software design; especially maintenance programmers must deal with such use cases after a software has been released. In the domain of software development, design patterns have been proposed as the best-known solutions for recurring problems in software design. Analogously, security patterns are best practices aiming at ensuring security. This thesis develops a deeper understanding of the nature of security patterns. It focuses on their validation and detection regarding the support of reviews and maintenance activities. The landscape of security patterns is diverse. Thus, published security patterns are collected and organized to identify software-related security patterns. The description of the selected software-security patterns is assessed, and they are compared against the common design patterns described by Gamma et al. to identify differences and issues that may influence the detection of security patterns. Based on these insights and a manual detection approach, we illustrate an automatic detection method for security patterns. The approach is implemented in a tool and evaluated in a case study with 25 real-world Android applications from Google Play. iii ZUSAMMENFASSUNG Die zunehmende und vielf¨altige Anzahl von Technologien, die mit dem Internet verbunden sind, zum Beispiel verteilte Unternehmenssysteme oder kleine elektronische Ger¨ate wie das Smartphone, r¨ucken das Thema IT-Sicherheit in den Vordergrund. Wir interagieren t¨aglich mit diesen Technologien und setzen viel Vertrauen in einen gut etablierten Software-Entwicklungsprozess, der u.a. auch die Gew¨ahrleistungvon Sicherheit beinhalten sollte. Sicherheitsl¨ucken treten jedoch in allen Arten von Software auf, wie die zunehmende Anzahl an ver¨offentlichten Sicherheitsl¨ucken in Software-Systemen zeigt. Daraus ergibt sich, dass eine bestehende Software aufgrund sich ¨andernder Anforderungen, Fehlern aber auch Sicherheitsl¨ucken modifiziert werden muss. Dadurch m¨ussen sich Entwickler und Entwicklerinnen beim Software-Design und vor allem bei der Softwarewartung mehr und mehr mit Sicherheitsproblemen und Sicherheitsfragestellungen auseinandersetzen. Im Bereich der Softwareentwicklung haben sich Entwurfsmuster als L¨osungen f¨urwiederkehrende Probleme beim Software-Design etabliert. Analog dazu sind Sicherheitsmuster (engl. security patterns) bew¨ahrte Praktiken, die auf die Gew¨ahrleistung von Sicherheit abzielen. Diese Arbeit vermittelt ein tieferes Verst¨andnis¨uber die Natur von Sicherheitsmustern und konzentriert sich dabei auf die Validierung und die Erkennung von Sicherheitsmustern zur Unterst¨utzungvon Pr¨ufungs-und Wartungsaktivit¨aten in der Softwareentwicklung. Die Landschaft der Sicherheitsmuster ist vielf¨altig. Daher werden in dieser Arbeit zuerst ver¨offentlichte Sicherheitsmuster gesammelt und kategorisiert, um softwarebezogene Sicherheitsmuster zu identifizieren. Anschließend wird die Beschreibung der ausgew¨ahlten Software-Sicherheitsmuster untersucht und mit den in der Softwareentwicklung bekannten Entwurfsmustern von Gamma et al. verglichen. Im Anschluss wird mit einem manuellen Verfahren versucht, implementierte Sicherheitsmuster in Softwaresystemen zu erkennen. Die aus den vorangegangenen Schritten gewonnenen Erkenntnisse fließen dann in eine automatische Erkennungsmethode f¨urSicherheitsmuster ein, die im Rahmen dieser Arbeit implementiert und mit einer Fallstudie mit 25 Applikationen von Google Play evaluiert wurde. v ACKNOWLEDGEMENTS Working on a Ph.D. is truly a marathon, and I would not have been able to complete this way without the aid and support of many people over the past eight years. Firstly, I would like to express my sincere gratitude to my advisor Karsten Sohr for the continuous support of my Ph.D. study and related research help from the very beginning to the end of this thesis. Without his guidance and constant feedback, this Ph.D. would not have been achievable. Besides my advisor, I am grateful to Hans-J¨orgKreowski who had taken over the supervision of this thesis in the final phase. Thanks to Rainer Koschke who provided me years ago an opportunity to join his research group and supported me in the beginning of my research. Special thanks to Bernhard Berger for sharing his Eclipse integrated Soot framework with me, our inspiring conversations about static analysis and security, and nevertheless our coffee walks to the GW2; I miss them. I also want to thank Dierk L¨udemann and Rebecca Tiarks for being there to listen when I needed an ear, especially when problems with my research and other stuff arose. Furthermore a big thank you to Immo Colonius, who reviewed this thesis and gave me constructive feedback on how to improve it. I am also deeply thankful to Ralf Streibl, Maxie and Malte Hesse, and all my friends who encouraged me to finish this thesis. Also many thanks to all the people that I met at various conferences as well as the members of SAFECode for the fruitful discussions, inspirations, and feedback on my work. I want to thank my mother Ingrid for her open ear and ongoing support of almost everything I do. Thanks to my daughters Cilia and Naomi for their patience when I could not play with them and had to work on my thesis or as Cilia always said: "am langen Text weiterschreiben". Finally, I would like to acknowledge the most important person in my life { my partner Thomas. There were times during the past eight years when everything seemed hopeless, and I didn't have any hope. I can honestly say that it was only his support and sometimes a kick on my backside when I needed one that made it possible for me to see this project through to the end. Michaela Bunke, 12th December 2018 vii TABLE OF CONTENTS I Prelude 1 1 Introduction 3 1.1 Motivation . .4 1.2 Problem Statement . .6 1.3 Approach . .7 1.3.1 Security Pattern Validation . .7 1.3.2 Security Pattern Detection . .8 1.4 Contributions . .9 1.5 Origin of Chapters and Related Publications . .9 1.6 Thesis Outline . 10 2 Background 13 2.1 Software Maintenance . 13 2.2 Software Reengineering . 14 2.3 Software Security . 14 2.3.1 Security by Design . 14 2.3.2 Security Bug Finder . 15 2.3.3 Software Security-Review . 15 2.4 Program Comprehension . 16 2.5 Patterns . 16 2.5.1 Origins of the Design Pattern Technique . 16 2.5.2 Software Design Patterns . 17 2.5.3 Security Patterns . 17 2.6 Conclusion . 18 II Validation 19 3 Literature Review 21 3.1 Article Selection and Discovery . 21 3.1.1 Process . 22 3.1.2 Result . 23 3.2 Summary . 27 ix 4 Classification 29 4.1 Requirements for Classifications . 30 4.2 Existing Classifications . 31 4.2.1 Design-Pattern Classifications . 31 4.2.2 Security-Pattern Classifications . 34 4.2.3 Classification Similarity . 37 4.2.4 Classification Distinction . 37 4.2.5 Resum´e . 39 4.3 Challenges in Categorizing Security Patterns . 39 4.3.1 Description Form Inspection . 39 4.3.2 Section Assessment/Examination . 40 4.3.3 Challenges for the Classification Approach . 41 4.4 Application-Domain Classification . 42 4.4.1 Organizing by Application-Domain . 42 4.4.2 The Application-Domain Criteria . 42 4.4.3 Result . 44 4.5 Merging Pattern Recognition and Security Needs . 44 4.5.1 Classification . 45 4.5.2 Pattern-Recognition Aspects . 45 4.5.3 Security Aspects . 47 4.5.4 Result . 47 4.6 Discussion . 48 4.7 Summary . 49 5 Analysis of Security-Pattern Descriptions 51 5.1 Introduction . 51 5.2 Identification of Additionally Used Sections . 53 5.2.1 Analysis . 54 5.2.2 Result . 55 5.3 Description-Form Alignment . 55 5.3.1 Process . 57 5.3.2 Section Mapping . 57 5.3.3 Security-Specific Sections . 60 5.4 Case Study . 61 5.4.1 Context . 61 5.4.2 Hypothesis and Measurable Terms . 61 5.4.3 Object-Selection Process . 61 5.4.4 Object Preparation . 64 5.4.5 Comparison Process . 64 5.4.6 Analyzing the Results . 64 5.4.7 Resum´e . 66 5.5 Summary . 66 6 Software-Security Patterns: Degree of Maturity 69 6.1 Introduction . 69 6.2 Patterns and the Software Life-Cycle . 71 6.2.1 Software Engineering|Forward Engineering . 72 6.2.2 Software Maintenance|Reverse Engineering . 73 6.2.3 Resum´e . 74 6.3 Possible Issues Affecting the Adoption of Patterns . 75 6.3.1 Terminology . 75 6.3.2 Classification . 76 6.3.3 Pattern Presentation . 77 6.3.4 Resum´e . 83 6.4 Summary . 83 III Recognition 85 7 Manual Security-Pattern Detection 87 7.1 Bauhaus Tool and Hierarchical Reflexion Analysis . 87 7.2 Early Case Studies . 88 7.2.1 Single Access Point Pattern . 89 7.2.2 Case Study: Spark . 90 7.2.3 Case Study: Simple Android Instant Messaging Application . 91 7.2.4 Resum´e . 92 7.3 Security Aspects and the RFG .
Load more

Recommended publications
  • Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp
    Kyle Brown An Introduction to Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp. 4001 Weston Parkway CSC591O Cary, North Carolina 27513-2303 April 7-9, 1997 919-481-4000 Raleigh, NC [email protected] http://www.ksccary.com Copyright (C) 1996, Kyle Brown, Bobby Woolf, and 1 2 Knowledge Systems Corp. All rights reserved. Overview Bobby Woolf Senior Member of Technical Staff O Patterns Knowledge Systems Corp. O Software Patterns 4001 Weston Parkway O Design Patterns Cary, North Carolina 27513-2303 O Architectural Patterns 919-481-4000 O Pattern Catalogs [email protected] O Pattern Languages http://www.ksccary.com 3 4 Patterns -- Why? Patterns -- Why? !@#$ O Learning software development is hard » Lots of new concepts O Must be some way to » Hard to distinguish good communicate better ideas from bad ones » Allow us to concentrate O Languages and on the problem frameworks are very O Patterns can provide the complex answer » Too much to explain » Much of their structure is incidental to our problem 5 6 Patterns -- What? Patterns -- Parts O Patterns are made up of four main parts O What is a pattern? » Title -- the name of the pattern » A solution to a problem in a context » Problem -- a statement of what the pattern solves » A structured way of representing design » Context -- a discussion of the constraints and information in prose and diagrams forces on the problem »A way of communicating design information from an expert to a novice » Solution -- a description of how to solve the problem » Generative:
    [Show full text]
  • Iot Design Patterns: Computational Constructs to Design, Build and Engineer Edge Applications
    2016 IEEE First International Conference on Internet-of-Things Design and Implementation IoT Design Patterns: Computational Constructs to Design, Build and Engineer Edge Applications Soheil Qanbari∗, Samim Pezeshki†, Rozita Raisi †, Samira Mahdizadeh∗, Rabee Rahimzadeh†, Negar Behinaein†, Fada Mahmoudi†, Shiva Ayoubzadeh †, Parham Fazlali†, Keyvan Roshani†, Azalia Yaghini†, Mozhdeh Amiri†, Ashkan Farivarmoheb†, Arash Zamani†, and Schahram Dustdar∗ ∗Distributed Systems Group, Vienna University of Technology, Vienna, Austria {qanbari, dustdar}@dsg.tuwien.ac.at †Baha’i Institute for Higher Education (BIHE) {firstname.lastname}@bihe.org Abstract—The objective of design patterns is to make design wiring approach of Hanmer [7]. This articulates the benefits robust and to abstract reusable solutions behind expressive of applying patterns by showing how each piece can fit into interfaces, independent of a concrete platform. They are ab- one integrated solution. stracted away from the complexity of underlying and enabling technologies. The connected things in IoT tend to be diverse With this motivation in mind, the paper continues in Sec- in terms of supported protocols, communication methods and tion II, with a brief review of how IoT design patterns are capabilities, computational power and storage. This motivates documented. Next, we introduce the diversity of our proposed us to look for more cost-effective and less resource-intensive patterns and how they are related to the edge applications IoT microservice models. We have identified a wide range of life-cycle in Section III. With some definitive clues on the design disciplines involved in creating IoT systems, that act as a seamless interface for collaborating heterogeneous things, and pattern language convention, we propose an edge provisioning suitable to be implemented on resource-constrained devices.
    [Show full text]
  • Structured Patterns Metamodel Standardtm Publication
    An OMG® Structured Patterns Metamodel StandardTM Publication OBJECT MANAGEMENT GROUP Structured Patterns Metamodel StandardTM V1.1 _______________________________________________ OMG Document Number: formal/2017-04-05 Release Date: July 2017 Standard document URL: http://www.omg.org/spec/SPMS/1.1 Normative Machine Consumable File(s): http://www.omg.org/spec/ SPMS /201 60301 /SPMS.xmi http://www.omg.org/spec/ SPMS/20160301/PHORML.xml http://www.omg.org/spec/ SPMS /201 60301 /APML.xmi _________________________________________________ Copyright © 2017, Object Management Group, Inc. Copyright © 2014, The Software Revolution, Inc. Copyright © 2014, CAST Copyright © 2014, KDM Analytics Copyright © 2014, Benchmark Consulting Copyright © 2014, eCube Systems Copyright © 2014, MITRE Copyright © 2014, University of North Carolina at Chapel Hill Copyright © 2014, École Polytechnique de Montréal USE OF SPECIFICATION – TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.
    [Show full text]
  • NSA Security-Enhanced Linux (Selinux)
    Integrating Flexible Support for Security Policies into the Linux Operating System http://www.nsa.gov/selinux Stephen D. Smalley [email protected] Information Assurance Research Group National Security Agency ■ Information Assurance Research Group ■ 1 Outline · Motivation and Background · What SELinux Provides · SELinux Status and Adoption · Ongoing and Future Development ■ Information Assurance Research Group ■ 2 Why Secure the Operating System? · Information attacks don't require a corrupt user. · Applications can be circumvented. · Must process in the clear. · Network is too far. · Hardware is too close. · End system security requires a secure OS. · Secure end-to-end transactions requires secure end systems. ■ Information Assurance Research Group ■ 3 Mandatory Access Control · A ªmissing linkº of security in current operating systems. · Defined by three major properties: ± Administratively-defined security policy. ± Control over all subjects (processes) and objects. ± Decisions based on all security-relevant information. ■ Information Assurance Research Group ■ 4 Discretionary Access Control · Existing access control mechanism of current OSes. · Limited to user identity / ownership. · Vulnerable to malicious or flawed software. · Subject to every user©s discretion (or whim). · Only distinguishes admin vs. non-admin for users. · Only supports coarse-grained privileges for programs. · Unbounded privilege escalation. ■ Information Assurance Research Group ■ 5 What can MAC offer? · Strong separation of security domains · System, application, and data integrity · Ability to limit program privileges · Processing pipeline guarantees · Authorization limits for legitimate users ■ Information Assurance Research Group ■ 6 MAC Implementation Issues · Must overcome limitations of traditional MAC ± More than just Multi-Level Security / BLP · Policy flexibility required ± One size does not fit all! · Maximize security transparency ± Compatibility for applications and existing usage.
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • An Access Control Model for Preventing Virtual Machine Escape Attack
    future internet Article An Access Control Model for Preventing Virtual Machine Escape Attack Jiang Wu ,*, Zhou Lei, Shengbo Chen and Wenfeng Shen School of Computer Engineering and Science, Shanghai University, Shanghai 200444, China; [email protected] (Z.L.); [email protected] (S.C.); [email protected] (W.S.) * Correspondence: [email protected]; Tel: +86-185-0174-6348 Academic Editor: Luis Javier Garcia Villalba Received: 26 March 2017; Accepted: 23 May 2017; Published: 2 June 2017 Abstract: With the rapid development of Internet, the traditional computing environment is making a big migration to the cloud-computing environment. However, cloud computing introduces a set of new security problems. Aiming at the virtual machine (VM) escape attack, we study the traditional attack model and attack scenarios in the cloud-computing environment. In addition, we propose an access control model that can prevent virtual machine escape (PVME) by adapting the BLP (Bell-La Padula) model (an access control model developed by D. Bell and J. LaPadula). Finally, the PVME model has been implemented on full virtualization architecture. The experimental results show that the PVME module can effectively prevent virtual machine escape while only incurring 4% to 8% time overhead. Keywords: virtual security; virtual machine escape; access control; BLP model; PVME model 1. Introduction Cloud computing treats IT resources, data and applications as a service provided to the user through network, which is a change in the way of how data is modeled. Currently, the world’s leading IT companies have developed and published their own cloud strategies, such as Google, Amazon, and IBM.
    [Show full text]
  • Multilevel Security (MLS)
    Multilevel Security (MLS) Database Security and Auditing Multilevel Security (MLS) Definition and need for MLS – Security Classification – Secrecy-Based Mandatory Policies: Bell- LaPadula Model – Integrity-based Mandatory Policies: The Biba Model – Limitation of Mandatory Policies Hybrid Policies – The Chinese Wall Policy Definition and need for MLS Multilevel security involves a database in which the data stored has an associated classification and consequently constraints for their access MLS allows users with different classification levels to get different views from the same data MLS cannot allow downward leaking, meaning that a user with a lower classification views data stored with a higher classification Definition and need for MLS Usually multilevel systems are with the federal government Some private systems also have multilevel security needs MLS relation is split into several single-level relations, A recovery algorithm reconstructs the MLS relation from the decomposed single-level relations At times MLS updates cannot be completed because it would result in leakage or destruction of secret information Definition and need for MLS In relational model, relations are tables and relations consist of tuples (rows) and attributes (columns) Example: Consider the relation SOD(Starship, Objective, Destination) Starship Objective Destination Enterprise Exploration Talos Voyager Spying Mars Definition and need for MLS The relation in the example has no classification associated with it in a relational model The same example in MLS with
    [Show full text]
  • Automating Testing with Autofixture, Xunit.Net & Specflow
    Design Patterns Michael Heitland Oct 2015 Creational Patterns • Abstract Factory • Builder • Factory Method • Object Pool* • Prototype • Simple Factory* • Singleton (* this pattern got added later by others) Structural Patterns ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy Behavioural Patterns 1 ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento Behavioural Patterns 2 ● Null Object * ● Observer ● State ● Strategy ● Template Method ● Visitor Initial Acronym Concept Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the S SRP software's specification should be able to affect the specification of the class) Open/closed principle: “Software entities … should be open O OCP for extension, but closed for modification.” Liskov substitution principle: “Objects in a program should be L LSP replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. Interface segregation principle: “Many client-specific I ISP interfaces are better than one general-purpose interface.”[8] Dependency inversion principle: One should “Depend upon D DIP Abstractions. Do not depend upon concretions.”[8] Creational Patterns Simple Factory* Encapsulating object creation. Clients will use object interfaces. Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Inject the factory into the object. Dependency Inversion Principle Depend upon abstractions. Do not depend upon concrete classes. Our high-level components should not depend on our low-level components; rather, they should both depend on abstractions. Builder Separate the construction of a complex object from its implementation so that the two can vary independently. The same construction process can create different representations.
    [Show full text]
  • A Survey of Architectural Styles.V4
    Survey of Architectural Styles Alexander Bird, Bianca Esguerra, Jack Li Liu, Vergil Marana, Jack Kha Nguyen, Neil Oluwagbeminiyi Okikiolu, Navid Pourmantaz Department of Software Engineering University of Calgary Calgary, Canada Abstract— In software engineering, an architectural style is a and implementation; the capabilities and experience of highest-level description of an accepted solution to a common developers; and the infrastructure and organizational software problem. This paper describes and compares a selection constraints [30]. These styles are not presented as out-of-the- of nine accepted architectural styles selected by the authors and box solutions, but rather a framework within which a specific applicable in various domains. Each pattern is presented in a software design may be made. If one were to say “that cannot general sense and with a domain example, and then evaluated in be called a layered architecture because the such and such a terms of benefits and drawbacks. Then, the styles are compared layer must communicate with an object other than the layer in a condensed table of advantages and disadvantages which is above and below it” then one would have missed the point of useful both as a summary of the architectural styles as well as a architectural styles and design patterns. They are not intended tool for selecting a style to apply to a particular project. The to be definitive and final, but rather suggestive and a starting paper is written to accomplish the following purposes: (1) to give readers a general sense of several architectural styles and when point, not to be used as a rule book but rather a source of and when not to apply them, (2) to facilitate software system inspiration.
    [Show full text]
  • Diplomarbeit Im Fachbereich Elektrotechnik & Informatik an Der
    Bachelor Thesis Prannoy Mulmi Design and Implementation of an Archive Microservice solution for the Multi-Agent Research and Simulation Distributed System Fakultät Technik und Informatik Faculty of Engineering and Computer Science Department Informations- und Department of Information and Elektrotechnik Electrical Engineering Prannoy Mulmi Design and Implementation of an Archive Microservice solution for the Multi-Agent Research and Simulation Distributed System Bachelor Thesis based on the study regulations for the Bachelor of Engineering degree programme Information Engineering at the Department of Information and Electrical Engineering of the Faculty of Engineering and Computer Science of the Hamburg University of Applied Sciences Supervising examiner : Prof. Dr. rer. nat. Henning Dierks Second Examiner : Prof. Dr. rer. nat. Thomas Clemen Day of delivery 23. Juli 2018 Prannoy Mulmi Title of the Bachelor Thesis Design and Implementation of an Archive Microservice solution for the Multi-Agent Research and Simulation Distributed System Keywords Distributed System, Microservice, Two-Phase commit protocol, Archive, Decentrali- zed data, Multi-Agent Research and Simulation (MARS) Abstract This thesis introduces the design and implementation of an Archive Microservice in the Multi-Agent Research and Simulation (MARS) framework. Due to the distributed architecture of the system, the process of the archive and restore is complex to imple- ment and maintain as there multiple possibilities of failure. This thesis uses different strategies to
    [Show full text]
  • (MVC) Design Pattern Untuk Aplikasi Perangkat Bergerak Berbasis Java
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Diponegoro University Institutional Repository Model-View-Controller (MVC) Design Pattern Untuk Aplikasi Perangkat Bergerak Berbasis Java Panji Wisnu Wirawan Program Studi Teknik Informatika, Universitas Diponegoro [email protected] Abstrak Design pattern merupakan salah satu teknik mendesain komponen perangkat lunak yang bisa digunakan kembali. MVC design pattern merupakan design pattern untuk komponen perangkat lunak yang memisahkan secara tegas antara model data, tampilan, dan kendali perangkat lunak. Artikel ini akan membahas MVC design pattern disertai kesesuaiannya dengan aplikasi perangkat bergerak berbasis Java. Bagian akhir artikel ini menunjukkan bagaimana MVC design pattern untuk aplikasi bergerak berbasis Java. Kata Kunci : MVC, design pattern , aplikasi perangkat bergerak berbasis Java ulang sehingga dapat meminimalkan usaha 1. Pendahuluan pengembangan aplikasi perangkat bergerak. Pada umumnya, aplikasi perangkat bergerak menggunakan Komponen perangkat lunak sudah semestinya GUI. Penggunaan MVC diharapkan bermanfaat untuk didesain dan diimplementasikan sehingga bisa pembuatan komponen perangkat lunak untuk aplikasi digunakan ulang ( reused ) pada perangkat lunak yang bergerak yang bisa digunakan ulang. [6] lain . Sebagai contoh penggunaan komponen perangkat lunak yang dapat digunakan ulang adalah Salah satu penelitian mengenai design pattern penggunaan text box , drop down menu dan untuk aplikasi perangkat bergerak berbasis Java telah sebagainya. dilakukan oleh Narsoo dan Mohamudally (2008). Narsoo dan Mohamudally (2008) melakukan Contoh lain dari komponen perangkat lunak identifikasi design pattern untuk mobile services adalah pola-pola tertentu untuk menyelesaikan menggunakan Java 2 Mobile Edition (J2ME). Mobile masalah yang disebut sebagai design pattern . Pola- services tersebut termasuk dalam behavioral pattern pola tersebut akan tetap sama untuk aplikasi yang yaitu add , edit , erase dan search .
    [Show full text]
  • Methods & Tools
    METHODS & TOOLS Practical knowledge for the software developer, tester and project manager ISSN 1661-402X Spring 2011 (Volume 19 - number 1) www.methodsandtools.com The Salesmen/Developers Ratio at Software Vendors Many of us might think that software is a technological industry. Maybe. But maybe not. If you consider Oracle or Microsoft, I suppose that few of us would consider them as technology leaders, but we will all recognize their financial strength and marketing power. Long lasting organizations in the software industry might have more financial strength than technological capabilities. The recent conflict between Oracle and the creator of Hudson, an open source continuous integration server, is just another episode in the opposition between developers- and salesmen-driven software companies. On one side you have Oracle, for which Hudson is just small project inherited from the Sun buyout and that owns the "Hudson" brand. On the other side, you find Kohsuke Kawaguchi, who created Hudson and wants keep some control on its development. Hudson has been "forked", the open source code being used to start another project. You now have a Jenkins CI project that includes most of the active Hudson contributors and a Hudson CI project backed by Oracle and Sonatype, the commercial company behind the Maven project. Everything is however not black and white. Kohsuke Kawaguchi has joined Cloudbees, a company that has some management and financing coming from ex-JBoss managers, people that know how to make money with open source software. These people are not working hard for the only sake of technology evolution. You can judge the main orientation of a company looking at its salesmen/developers ratios.
    [Show full text]