DOCSLIB.ORG

Software Architecture and Design Patterns/17Is72

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Architecture and Design Patterns/17Is72 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS/17IS72 Department of ISE BMS Institute of Technology and Mgmt Course Outcomes CO1 Understand the basic concepts to identify state & behaviour of real world objects. CO2 Apply Object Oriented Analysis and Design concepts to solve complex problems. CO3 Construct various UML models using the appropriate notation for specific problem context. CO4 Design models to Show the importance of systems analysis and design in solving complex problems using case studies. CO5 Study of Pattern Oriented approach for real world problems. Program Outcomes COS/P OS PO PO PO PO1 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2 2 3 4 CO1 3 - - - - - - - - - - - - - CO2 3 - - - - - - - - - - - - - CO3 - 3 - - - - - - - - - - 2 - CO4 - - 3 - - - - - - - - 3 - DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt CO5 - - 3 - - - - - - - - - - Syllabus and Text Books Module-1: Introduction: what is a design pattern? Describing design patterns, the catalog of design pattern, organizing the catalog, how design patterns solve design problems, how to select a design pattern, how to use a design pattern. What is object-oriented development? , key concepts of object oriented design other related concepts, benefits and drawbacks of the paradigm Module-2: Analysis a System: overview of the analysis phase, stage 1: gathering the requirements functional requirements specification, defining conceptual classes and relationships, using the knowledge of the domain. Design and Implementation, discussions and further reading. Module-3: Design Pattern Catalog: Structural patterns, Adapter, bridge, composite, decorator, facade, flyweight, proxy. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt Module-4: Interactive systems and the MVC architecture: Introduction , The MVC architectural pattern, analyzing a simple drawing program , designing the system, designing of the subsystems, getting into implementation, implementing undo operation , drawing incomplete items, adding a new feature , pattern based solutions. Module-5: Designing with Distributed Objects: Client server system, java remote method invocation, implementing an object oriented system on the web (discussions and further reading) a note on input and output, selection statements, loops arrays. Text Books: 1. Object-oriented analysis, design and implementation, brahma dathan, sarnath rammath, universities press,2013 2. Design patterns, erich gamma, Richard helan, Ralph johman , john vlissides ,PEARSON Publication,2013. Reference Books: 1. Frank Bachmann, RegineMeunier, Hans Rohnert “Pattern Oriented Software Architecture” –Volume 1, 1996. 2. William J Brown et al., "Anti-Patterns: Refactoring Software, Architectures and Projects in Crisis", John Wiley, 1998. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt Module-1 : Introduction What Is a Design Pattern? Christopher Alexander says: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same thing twice.” Borrowed from Civil and Electrical Engineering domains. A technique to repeat designer success. A (Problem, Solution) pair DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt Essential Elements A pattern has four essential elements: The pattern name that we use to describe a design problem, The problem that describes when to apply the pattern, The solution that describes the elements that make up the design, and The consequences that are the results and trade-offs of applying the pattern. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt Design Patterns Are Not About Design • Design patterns are not about designs such as linked lists and hash tables that can be encoded in classes and reused as is. • Design patterns are not complex, domain-specific designs for an entire application or subsystem. • One person's pattern can be another person's primitive building block. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt What is and isn’t a design pattern The design patterns are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt What is and isn’t a design pattern • A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. • The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities. • Each design pattern focuses on a particular object-oriented design problem or issue. • It describes when it applies, whether it can be applied in view of other design constraints, and the consequences and trade-offs of its use. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt What is and isn’t a design pattern • Although design patterns describe object-oriented designs, they are based on practical solutions that have been implemented in mainstream object-oriented programming languages like Smalltalk and C++ rather than procedural languages(Pascal, C, Ada) or more dynamic object-oriented languages (CLOS, Dylan, Self) • The choice of programming language is important because it influences one's point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. • We might have included design patterns called "Inheritance", "Encapsulation," and "Polymorphism." DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt Design Patterns in Smalltalk MVC The Model/View/Controller (MVC) triad of classes is used to build user interfaces in Smalltalk-80. MVC consists of three kinds of objects 1. Model is the application object, 2. View is its screen presentation, 3. Controller defines the way the user interface reacts to user input. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt MVC decouples them to increase flexibility and reuse. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt MVC decouples them to increase flexibility and reuse. 1. MVC decouples views and models by establishing a subscribe/notify protocol between them. 2. A view must ensure that its appearance reflects the state of the model. 3. Whenever the model's data changes, the model notifies views that depend on it. 4. In response, each view gets an opportunity to update itself. 5. This approach lets you attach multiple views to a model to provide different presentations. 6. We can also create new views for a model without rewriting it. 7. The model contains some data values, and the views defining a spreadsheet, histogram, and pie chart display these data in various ways. 8. The model communicates with its views when its values change, and the views communicate with the model to access these values. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt Describing Design Patterns Describing the design patterns in graphical notations, simply capture the end product of the design process as relationships between classes and objects. • In order to reuse the design, one must record decisions, alternatives and trade-offs. • Also need some concrete examples, • Describe design pattern using consistent format. DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt A common way to describe a design pattern is the use of the following template: 1. Pattern Name and Classification 2. Intent 3. Also Known As 4. Motivation (Problem, Context) 5. Applicability (Solution) 6. Structure (a detailed specification of structural aspects) 7. Participants, Collaborations (Dynamics) 8. Implementation 9. Sample code 10. Known Uses 11. Consequences 12. Related patterns DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt The Catalog of Design Patterns (23 patterns) Pattern Name purpose Abstract Factory Provide an interface for creating families of related or (87) dependent objects without specifying their concrete classes. Adapter ( 139 ) • Convert the interface of a class into another interface clients expect. • Lets classes work together with incompatible interfaces. Bridge(1 51) • Decouple an abstraction from its implementation so that the two can vary independently. Builder (97) • Separate the construction of a complex object from its representation • So that the same construction process can create different representations. Chain of • Avoid coupling the sender of a request to its receiver by Responsibility giving more than one object a chance to handle the (223) request. • Chain the receiving objects and pass the request along the DepartmentDepartment of of ISE ISE BMSBMS Institute Institute of of Technology Technology and and Mgmt Mgmt chain until an object handles
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]
  • Capturing Interactions in Architectural Patterns
    Capturing Interactions in Architectural Patterns Dharmendra K Yadav Rushikesh K Joshi Department of Computer Science and Engineering Department of Computer Science and Engineering Indian Institute of Technology Bombay Indian Institute of Technology Bombay Powai, Mumbai 400076, India Powai, Mumbai 400076, India Email: [email protected] Email: [email protected] TABLE I Abstract—Patterns of software architecture help in describing ASUMMARY OF CCS COMBINATORS structural and functional properties of the system in terms of smaller components. The emphasis of this work is on capturing P rimitives & Descriptions Architectural the aspects of pattern descriptions and the properties of inter- Examples Significance component interactions including non-deterministic behavior. Prefix (.) Action sequence intra-component Through these descriptions we capture structural and behavioral p1.p2 sequential flow specifications as well as properties against which the specifications Summation (+) Nondeterminism choice within a component are verified. The patterns covered in this paper are variants of A1 + A2 Proxy, Chain, MVC, Acceptor-Connector, Publisher-Subscriber Composition (|) Connect matching multiple connected and Dinning Philosopher patterns. While the machines are CCS- A1 | A2 i/o ports in assembly components based, the properties have been described in Modal µ-Calculus. Restriction (\) Hiding ports from Internal The approach serves as a framework for precise architectural A\{p1, k1, ..} further composition features descriptions. Relabeling ([]) Renaming of ports syntactic renaming A[new/old, ..] I. INTRODUCTION In component/connector based architectural descriptions [6], [13], components are primary entities having identities in the represents interface points as ports uses a subset of CSP for system and connectors provide the means for communication it’s formal semantics.
    [Show full text]
  • Wiki As Pattern Language
    Wiki as Pattern Language Ward Cunningham Cunningham and Cunningham, Inc.1 Sustasis Foundation Portland, Oregon Michael W. Mehaffy Faculty of Architecture Delft University of Technology2 Sustasis Foundation Portland, Oregon Abstract We describe the origin of wiki technology, which has become widely influential, and its relationship to the development of pattern languages in software. We show here how the relationship is deeper than previously understood, opening up the possibility of expanded capability for wikis, including a new generation of “federated” wiki. [NOTE TO REVIEWERS: This paper is part first-person history and part theory. The history is given by one of the participants, an original developer of wiki and co-developer of pattern language. The theory points toward future potential of pattern language within a federated, peer-to-peer framework.] 1. Introduction Wiki is today widely established as a kind of website that allows users to quickly and easily share, modify and improve information collaboratively (Leuf and Cunningham, 2001). It is described on Wikipedia – perhaps its best known example – as “a website which allows its users to add, modify, or delete its content via a web browser usually using a simplified markup language or a rich-text editor” (Wikipedia, 2013). Wiki is so well established, in fact, that a Google search engine result for the term displays approximately 1.25 billion page “hits”, or pages on the World Wide Web that include this term somewhere within their text (Google, 2013a). Along with this growth, the definition of what constitutes a “wiki” has broadened since its introduction in 1995. Consider the example of WikiLeaks, where editable content would defeat the purpose of the site.
    [Show full text]
  • Automatic Verification of Java Design Patterns
    Automatic Verification of Java Design Patterns Alex Blewitt, Alan Bundy, Ian Stark Division of Informatics, University of Edinburgh 80 South Bridge, Edinburgh EH1 1HN, UK [email protected] [email protected] [email protected] Abstract 2. Design patterns There are a number of books which catalogue and de- Design patterns are widely used by object oriented de- scribe design patterns [4, 1, 6] including an informal de- signers and developers for building complex systems in ob- scription of the key features and examples of their use. ject oriented programming languages such as Java. How- However, at the moment there are no books which attempt ever, systems evolve over time, increasing the chance that to formalise these descriptions, possibly for the following the pattern in its original form will be broken. reasons: We attempt to show that many patterns (implemented in Java) can be verified automatically. Patterns are defined 1. The implementation (and description) of the pattern is in terms of variants, mini-patterns, and constraints in a language-specific. pattern description language called SPINE. These specifi- 2. There are often several ways to implement a pattern cations are then processed by HEDGEHOG, an automated within the same language. proof tool that attempts to prove that Java source code 3. Formal language descriptions are not common within meets these specifications. the object oriented development community. Instead, each pattern is presented as a brief description, and an example of its implementation and use. Designers and developers are then expected to learn the ‘feel’ of a pat- 1.
    [Show full text]
  • Enterprise Integration Patterns Introduction
    Enterprise Integration Patterns Gregor Hohpe Sr. Architect, ThoughtWorks [email protected] July 23, 2002 Introduction Integration of applications and business processes is a top priority for many enterprises today. Requirements for improved customer service or self-service, rapidly changing business environments and support for mergers and acquisitions are major drivers for increased integration between existing “stovepipe” systems. Very few new business applications are being developed or deployed without a major focus on integration, essentially making integratability a defining quality of enterprise applications. Many different tools and technologies are available in the marketplace to address the inevitable complexities of integrating disparate systems. Enterprise Application Integration (EAI) tool suites offer proprietary messaging mechanisms, enriched with powerful tools for metadata management, visual editing of data transformations and a series of adapters for various popular business applications. Newer technologies such as the JMS specification and Web Services standards have intensified the focus on integration technologies and best practices. Architecting an integration solution is a complex task. There are many conflicting drivers and even more possible ‘right’ solutions. Whether the architecture was in fact a good choice usually is not known until many months or even years later, when inevitable changes and additions put the original architecture to test. There is no cookbook for enterprise integration solutions. Most integration vendors provide methodologies and best practices, but these instructions tend to be very much geared towards the vendor-provided tool set and often lack treatment of the bigger picture, including underlying guidelines and principles. As a result, successful enterprise integration architects tend to be few and far in between and have usually acquired their knowledge the hard way.
    [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]
  • Addison Wesley, 2000, Pp
    ------==Proudly Presented by MODELER==------ preface.fm Page xv Wednesday, June 6, 2001 4:18 PM Preface Design patterns and object-oriented programming. They hold such promise to make your life as a software designer and developer eas- ier. Their terminology is bandied about every day in the technical and even the popular press. But it can be hard to learn them, to become proficient with them, to understand what is really going on. Perhaps you have been using an object-oriented or object-based language for years. Have you learned that the true power of objects is not inheritance but is in “encapsulating behaviors”? Perhaps you are curious about design patterns and have found the literature a bit too esoteric and high-falutin. If so, this book is for you. It is based on years of teaching this material to software developers, both experienced and new to object orientation. It is based upon the belief—and our experience—that once you understand the basic principles and motivations that underlie these concepts, why they are doing what they do, your learning curve will be incredibly shorter. And in our discussion of design patterns, you will under- stand the true mindset of object orientation, which is a necessity before you can become proficient. As you read this book, you will gain a solid understanding of the ten most essential design patterns. You will learn that design pat- terns do not exist on their own, but are supposed to work in con- cert with other design patterns to help you create more robust applications.
    [Show full text]
  • Object-Oriented Analysis, Design and Implementation
    Undergraduate Topics in Computer Science Brahma Dathan Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition Undergraduate Topics in Computer Science Undergraduate Topics in Computer Science (UTiCS) delivers high-quality instruc- tional content for undergraduates studying in all areas of computing and information science. From core foundational and theoretical material to final-year topics and applications, UTiCS books take a fresh, concise, and modern approach and are ideal for self-study or for a one- or two-semester course. The texts are all authored by established experts in their fields, reviewed by an international advisory board, and contain numerous examples and problems. Many include fully worked solutions. More information about this series at http://www.springer.com/series/7592 Brahma Dathan • Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition 123 Brahma Dathan Sarnath Ramnath Department of Information and Computer Department of Computer Science Science and Information Technology Metropolitan State University St. Cloud State University St. Paul, MN St. Cloud, MN USA USA Series editor Ian Mackie Advisory Board Samson Abramsky, University of Oxford, Oxford, UK Karin Breitman, Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil Chris Hankin, Imperial College London, London, UK Dexter Kozen, Cornell University, Ithaca, USA Andrew Pitts, University of Cambridge, Cambridge, UK Hanne Riis Nielson, Technical University of Denmark, Kongens Lyngby, Denmark Steven Skiena, Stony Brook University, Stony Brook, USA Iain Stewart, University of Durham, Durham, UK A co-publication with the Universities Press (India) Private Ltd., licensed for sale in all countries outside of India, Pakistan, Bhutan, Bangladesh, Sri Lanka, Nepal, The Maldives, Middle East, Malaysia, Indonesia and Singapore.
    [Show full text]
  • Principles of Design
    Principles of Design Balance Proportion/Scale Emphasis Rhythm Introduction The principles of design are essential to the development and production of clothing used by individuals and families around the world. Each principle has a specific role in creating an aesthetically pleasing garment or ensemble. The principles of design consist of: balance, proportion (also referred to as scale), emphasis, and rhythm. When a garment or ensemble uses the elements and principles of design to create a visual unity, harmony is achieved. Garments often integrate more than one principle, while drawing from the elements of design to create a cohesive look. The following discussion will present background information on each of the principles of design and applications to clothing design and construction. Balance According to Wolfe (2011) balance implies that there is an equilibrium or uniformity among the parts of a design (p. 205). To achieve balance, a garment or ensemble should have equal visual weight throughout the design. The use of structural features, added embellishments, or decorations to a garment contribute to the appearance of a garment or ensemble being balanced or not. A clothing designer can utilize surface designs on fabric to construct a garment creating visual balance. Further, color, line, and texture can impact the balance of a design. For example, cool and light colors have less visual weight than dark, warm colors. If an individual is wearing a small amount of a dark, warm color it can be balanced out with a larger amount of cool, light colors. Balance used in clothing design can be categorized into two groups: Formal and Informal Balance.
    [Show full text]
  • Co-Occurrence of Design Patterns and Bad Smells in Software Systems
    XI Brazilian Symposium on Information System, Goi^ania,GO, May 26-29, 2015. Co-Occurrence of Design Patterns and Bad Smells in Software Systems: An Exploratory Study Bruno Cardoso Eduardo Figueiredo Software Engineering Lab (LabSoft) Software Engineering Lab (LabSoft) Federal University of Minas Gerais (UFMG) Federal University of Minas Gerais (UFMG) Belo Horizonte, MG - Brazil Belo Horizonte, MG - Brazil [email protected] [email protected] ABSTRACT In a previous work [1], we performed a systematic literature A design pattern is a general reusable solution to a recurring review in order to understand how studies investigate these two problem in software design. Bad smells are symptoms that may topics, design patterns and bad smells, together. Our results indicate something wrong in the system design or code. showed that, in general, studies have a narrow view concerning Therefore, design patterns and bad smells represent antagonistic the relation between these concepts. Most of them focus on structures. They are subject of recurring research and typically refactoring opportunities. Among these, some tools [3][7][15][17] appear in software systems. Although design patterns represent have been proposed to identify code fragments that can be good design, their use is often inadequate because their refactored to patterns. Other studies [2][6] establish a structural implementation is not always trivial or they may be unnecessarily relationship between the terms design pattern and bad smell. In employed. The inadequate use of design patterns may lead to a addition, there are reported cases in the literature where the use of bad smell. Therefore, this paper performs an exploratory study in design patterns may not always be the best option and the wrong order to identify instances of co-occurrences of design patterns use of a design pattern can even introduce bad smells in code [19] and bad smells.
    [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]
  • (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]