Chapter 18. Software Reuse
|
|
- Brianna Hubbard
- 5 years ago
- Views:
Transcription
1 Chapter 18 Software Reuse Ian Sommerville Lutz Prechelt Ian Sommerville 2004, Software Engineering, 7th edition, 1
2 Objectives To explain the benefits of software reuse and some reuse problems To discuss several different ways to implement software reuse To explain how reusable concepts can be represented as patterns or embedded in program generators To discuss COTS reuse To describe the development of software product lines Ian Sommerville 2004, Software Engineering, 7th edition, 2
3 Topics covered The reuse landscape Design patterns Generator based reuse Application frameworks Application system reuse Ian Sommerville 2004, Software Engineering, 7th edition, 3
4 Software reuse In most engineering disciplines, systems are designed by composing existing components that have been used in other systems. Software engineering has long been more focused on original development but it is now recognised that to reduce cost and to improve quality and time-to-market, we need to adopt a design process that is based on systematic reuse. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 4
5 Reuse-based software engineering Application system reuse The whole of an application system may be reused either by incorporating it without change into other systems or by developing application families. Component reuse Components of an application from sub-systems to single objects may be reused. Covered in Chapter 19. Object and function reuse Software components that implement a single welldefined object or function may be reused. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 5
6 Reuse benefits (1) Increased dependability Previously used SW tends to have fewer defects. Reduced process risk Building a component can fail more easily than reusing an existing one. Particularly true for large, complex components (subsystems). Sometimes not true, if the adaptability of the reusable component is unclear. Effective use of specialists Rare knowledge is encapsulated in a component and is then more readily and widely available. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 6
7 Reuse benefits (2) Standards compliance Reusing components can promote the adherence to standards (e.g. user interface look-and-feel). This improves usability of a component (for programmers and/or for end-users). Accelerated development Often more important than anything else. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 7
8 Reuse problems (1) Increased maintenance cost External changes to a reused (COTS) component may force changes to the reusing software. Required changes to a reused component may be more difficult to have than for a custom component. Lack of tool support There is little support for maintaining a catalog of reusable components and for finding components. Development tools do not support development with all kinds of reusable components well. Not-invented-here syndrome Many software engineers tend to prefer rewriting a component over reusing it. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 8
9 Reuse problems (2) The reuse barrier: 1. A software developer will only search for a reusable component if s/he expects to find an appropriate one. 2. S/he will only find it if it is described in a way s/he can recognize as providing a solution. 3. S/he will only use it if s/he can understand it. 4. Use will only be successful if the component can be adapted to the problem at hand. The whole process will start only if the developer expects all steps to be successful in the beginning. Reuse works well for many general-purpose components, but is difficult for highly domainspecific ones. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 9
10 The reuse landscape Although reuse is often simply thought of as the reuse of system components, there are many different approaches to reuse that may be used. Reuse is possible at a range of granularity levels from simple functions to complete application systems at a range of abstraction levels from requirements to code etc. at a range of scales from one-time-reuse to mass-marketing The reuse landscape covers the range of possible reuse techniques. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 10
11 The reuse landscape Design patterns Component frameworks Application product lines Aspect-oriented software development Component-based development Service-oriented systems Legacy system wrapping Program libraries COTS integration Configurable vertical applications Program generators Ian Sommerville 2004, Software Engineering, 7th edition, 11
12 Reuse approaches (1) Design patterns Componentbased development Application frameworks Legacy system wrapping Service-oriented systems Generic abstractions that occur across applications are represented as design patterns that show abstract and concrete objects and interactions. Systems are developed by integrating components (collections of objects) that conform to componentmodel standards. This is covered in Chapter 19. Collections of abstract and concrete classes that can be adapted and extended to create application systems. Legacy systems (see Chapter 2) that can be 'wrapped' by defining a set of interfaces and providing access to these legacy systems through these interfaces. Systems are developed by linking shared services that may be externally provided. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 12
13 Reuse approaches (2) Application product lines COTS integration Configurable vertical applications Program libraries Program generators Aspect-oriented software development An application type is generalised around a common architecture so that it can be adapted in different ways for different customers. Systems are developed by integrating existing application systems. A generic system is designed so that it can be configured to the needs of specific system customers. Class and function libraries implementing commonlyused abstractions are available for reuse. A generator system embeds knowledge of a particular types of application and can generate systems or system fragments in that domain. Shared components are woven into an application at different places when the program is compiled. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 13
14 Reuse planning factors The development schedule for the software. The expected software lifetime. The background, skills and experience of the development team. The criticality of the software and its nonfunctional requirements. The application domain. The execution platform for the software. Ian Sommerville 2004, Software Engineering, 7th edition, 14
15 Concept reuse When you reuse program or design components, you have to follow the design decisions made by the original developer of the component. This may limit the opportunities for reuse. However, a more abstract form of reuse is concept reuse: A particular approach is described in an implementationindependent way. At reuse time, an implementation is then developed. The two main approaches to concept reuse are: Design patterns; Generative programming. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 15
16 Design patterns A design pattern is a way of reusing abstract knowledge about a problem and its solution. A pattern is a description of the problem and the essence of its solution. It should be sufficiently abstract to be reused in different settings. Many patterns aim at flexibility and rely on object characteristics such as inheritance and polymorphism. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 16
17 Pattern elements Name A meaningful pattern identifier. Problem description Context, requirements, constraints Solution description Not a concrete design but a template for a design solution that can be instantiated in different ways. Consequences The results, variants and trade-offs when applying the pattern. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 17
18 Multiple displays C D B A A B C D Observer 1 Subject A: 40 B: 25 C: 15 D: 20 Observer 2 Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 18
19 The Observer pattern Name Observer. Description Separates the display of object state from the object itself. Problem description Used when multiple displays of state are needed and must be added and removed at run-time. Solution description See slide with UML description. Consequences Optimisations to enhance display performance must be designed for all observers in advance. Ian Sommerville 2004, Software Engineering, 7th edition, 19
20 The Observer pattern Subject Observer Attach (Observer) Detach (Observer) Notify () for all o in observers o -> Update () Update () ConcreteSubject ConcreteObserver GetState () return subjectstate Update () observerstate = subject -> GetState () subjectstate observerstate Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 20
21 Generator-based reuse Program generators involve the reuse of standard patterns and algorithms. These are embedded in the generator and parameterised by user commands. Generator-based reuse is possible when domain abstractions and their mapping to executable code can be identified. A domain-specific language is used to compose and control these abstractions. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 21
22 Types of program generator Types of program generator Application generators for business data processing; Parser and lexical analyser generators for language processing (e.g. compilers); Code generators in CASE tools. Generator-based reuse is very cost-effective but its applicability is limited to some application domains. It is easier for end-users to develop programs using generators compared to other componentbased approaches to reuse. Ian Sommerville 2004, Software Engineering, 7th edition, 22
23 Aspect-oriented development Aspect-oriented development (AOD) addresses a major software engineering problem: the separation of concerns. Concerns are often not simply associated with application functionality but are cross-cutting. E.g. all components may monitor their own operation, all components may have to maintain security, etc. In AOD, cross-cutting concerns are implemented separately (as 'aspects') and are dynamically woven into a program. The concern code is reused and the new system is generated by the aspect weaver. Requires extensions to existing programming languages. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 23
24 Aspect-oriented development Aspect 1 Aspect 2 Input source code <statements 1> join point 1 <statements 2> join point 2 <statements 3> Aspect Weaver Generated code <statements 1> Aspect 1 <statements 2> Aspect 2 <statements 3> Any join point may be filled by more than one aspect Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 24
25 Application frameworks A framework is a conceptually complete design plus an incomplete implementation. Typically object-oriented: a collection of abstract and concrete classes and the interfaces between them. Describes a sub-system or complete system. Implementation is completed by adding components to fill in the missing parts. Miniature example: java.util.collections.collection: static void sort(list list) Requires that all elements of the list implement interface Comparable: int compareto(object o) Reusable 'sort' will call user-defined function 'compareto'. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 25
26 Types of framework System infrastructure frameworks Support the development of system infrastructures such as communications, user interfaces and compilers. Middleware integration frameworks Standards and classes that support resource management and component communication. Enterprise application frameworks Support the development of specific types of application such as telecommunications or financial systems. A problem with frameworks is their complexity. It takes long to learn using them effectively. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 26
27 Model-View-Controller (MVC) System infrastructure framework for GUI design. Allows for multiple presentations of an object and separate interactions with each. Using an MVC framework involves the instantiation of a number of design patterns. E.g. Observer pattern, Strategy pattern, maybe Composite pattern. Parts of the implementations of these patterns have to be provided by the framework user. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 27
28 Model-View-Controller User inputs Controller state view modification messages View state Controller methods View methods Model edits Model state Model queries and updates Model methods Ian Sommerville 2004, Software Engineering, 7th edition, 28
29 Application system reuse Involves the reuse of entire application systems either by configuring a system for an environment or by integrating two or more systems to create a new application. Two approaches covered here: COTS product integration; Product line development. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 29
30 COTS product reuse COTS = Commercial Off-The-Shelf software. COTS systems are usually complete application systems that offer an API (Application Programming Interface). Building large systems by integrating COTS systems is now a viable development strategy for some types of system such as E-commerce systems. The key benefit is faster application development and, usually, lower development costs. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 30
31 COTS design choices Which COTS products offer the most appropriate functionality? There may be several similar products that may be used. Can I later switch my system over to a different COTS product if I have to? If the COTS is decomissioned or does not support future requirements. How will data be exchanged? Individual products use their own data structures and formats. What features of the product will actually be used? Most products have more functionality than is needed. You should try to deny access to unused functionality. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 31
32 E-procurement system Client Web browser system Server E-commerce system Adaptor Ordering and invoicing system system Adaptor Ian Sommerville 2004, Software Engineering, 7th edition, 32
33 COTS products reused On the client, standard and web browsing programs are used. On the server, an e-commerce platform has to be integrated with an existing ordering system. This involves writing an adaptor so that they can exchange data. An system is also integrated to generate e- mail for clients. This also requires an adaptor to receive data from the ordering and invoicing system. Ian Sommerville 2004, Software Engineering, 7th edition, 33
34 COTS system integration problems Lack of control over functionality and performance COTS systems may be less effective than they appear. Problems with COTS system inter-operability Different COTS systems may make conflicting assumptions so that integration can be difficult. No control over system evolution COTS vendors, not system users control evolution. Finite support from COTS vendors COTS vendors may not offer support over the lifetime of the product. Ian Sommerville 2004, Software Engineering, 7th edition, 34
35 Software product lines Software product lines or application families are applications with generic functionality that can be adapted and configured for use in a specific context. Adaptation may involve: Component and system configuration; Adding new components to the system; Selecting from a library of existing components; Modifying components to meet new requirements. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 35
36 COTS product specialisation Platform specialisation Different versions of the application are developed for different platforms. Environment specialisation Different versions of the application are created to handle different operating environments e.g. different types of communication equipment. Functional specialisation Different versions of the application are created for customers with different requirements. Or for different marketing needs (e.g. "light" versions). Process specialisation Different versions of the application are created to support different business processes. Ian Sommerville 2004, Software Engineering, 7th edition, 36
37 COTS configuration Deployment-time configuration A generic system is configured by embedding knowledge of the customer s requirements and business processes. The software itself is not changed. Design-time configuration A common generic code is adapted and changed according to the requirements of particular customers. Creates a specific version of the software. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 37
38 Deployment-time configuration: ERP systems An Enterprise Resource Planning (ERP) system is a generic system that supports common business processes such as ordering and invoicing, production planning, etc. These are very widely used in large companies and represent probably the most common form of hugescale software reuse. The generic core is adapted at deployment time by including modules and by incorporating knowledge of specific business processes and rules. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 38
39 ERP system organisation Configuration planning tool Configuration database Generic ERP system System database Ian Sommerville 2004, Software Engineering, 7th edition, 39
40 Design time configuration: Product lines Software product lines that are configured at design time are instantiations of generic application architectures as discussed in Chapter 13. Generic products usually emerge after experience with specific products. Architectures must be structured in such a way to separate different sub-systems and to allow them to be modified e.g. by separating entities strongly in the architecture: The higher levels in the system access entities through descriptions rather than directly. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 40
41 Generic resource management system User inter face User authentication Resource delivery Query management Resource management Resource policy control Resource allocation Transaction management Resource database Ian Sommerville 2004, Software Engineering, 7th edition, 41
42 Vehicle despatching A specialised resource management system where the aim is to allocate resources (vehicles) to handle incidents. Adaptations include: At the UI level, there are components for operator display and communications; At the I/O management level, there are components that handle authentication, reporting and route planning; At the resource management level, there are components for vehicle location and despatch, managing vehicle status and incident logging; The database includes equipment, vehicle and map databases. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 42
43 A vehicle despatching system User interface Comms system inter face Operator authentication Map and route planner Report generator Query manager Vehicle status manager Incident logger Vehicle despatcher Equipment manager Vehicle locator Equipment database Transaction management Vehicle database Incident log Map database Ian Sommerville 2004, Software Engineering, 7th edition, 43
44 Product instance development Renegotiate requirements Elicit stakeholder requirements Choose closest-fit family member Adapt existing system Deliver new family member Ian Sommerville 2004, Software Engineering, 7th edition, 44
45 Product instance development Elicit stakeholder requirements Use existing family member as a prototype. Choose closest-fit family member Find the family member that best meets the requirements. Re-negotiate requirements Adapt requirements as necessary to capabilities of the software. Adapt existing system Develop new modules and make changes for family member. Deliver new family member Document key features for further member development. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 45
46 Key points Advantages of reuse are lower costs, faster software development and lower risks. Successful reuse requires overcoming a number of barriers: Creation/availability, discovery, understanding, fitness, trust, adaptation, evolution. Design patterns are high-level abstractions that describe and discuss problem/solution pairs. Reusable concepts may be embedded in a program generator system. Application frameworks are collections of concrete and abstract objects that are designed for reuse through specialisation. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 46
47 Key points (2) COTS product reuse is concerned with the reuse of large, off-the-shelf systems. Problems with COTS reuse include lack of control over functionality, performance, and evolution and problems with inter-operation. ERP systems are created by configuring a generic system with information about a customer s business. Software product lines are related applications developed around a common core of shared functionality. Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 47
Seminar report Software reuse
A Seminar report On Software reuse Submitted in partial fulfillment of the requirement for the award of degree of Bachelor of Technology in Computer Science SUBMITTED TO: www.studymafia.com SUBMITTED BY:
More informationDr. Tom Hicks. Computer Science Department Trinity University
Dr. Tom Hicks Computer Science Department Trinity University 1 1 About Design With Reuse 2 Software Reuse Why Do We Care About Reuse? Historically: In Most Engineering Disciplines, Systems are Designed
More informationSOFTWARE ENGINEERING. To discuss several different ways to implement software reuse. To describe the development of software product lines.
SOFTWARE ENGINEERING DESIGN WITH COMPONENTS Design with reuse designs and develops a system from reusable software. Reusing software allows achieving better products at low cost and time. LEARNING OBJECTIVES
More informationSoftware Engineering
Software Engineering chap 4. Software Reuse 1 SuJin Choi, PhD. Sogang University Email: sujinchoi@sogang.ac.kr Slides modified, based on original slides by Ian Sommerville (Software Engineering 10 th Edition)
More informationPart 4. Development. -Software Reuse - Component-Based Software Engineering. JUNBEOM YOO Ver. 1.
Software Engineering Part 4. Development - Rapid Software Development -Software Reuse - Component-Based Software Engineering Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006.
More informationSoftware Reuse and Component-Based Software Engineering
Software Reuse and Component-Based Software Engineering Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Contents Software Reuse Components CBSE (Component-Based Software Engineering) Domain Engineering
More informationStudy of Component Based Software Engineering
Study of Based Software Ishita Verma House No.4, Village Dayalpur Karawal Nagar Road Delhi-110094, India ish.v.16@gmail.com Abstract based engineering is an approach of development that emphasizes the
More informationMinsoo Ryu. College of Information and Communications Hanyang University.
Software Reuse and Component-Based Software Engineering Minsoo Ryu College of Information and Communications Hanyang University msryu@hanyang.ac.kr Software Reuse Contents Components CBSE (Component-Based
More informationChapter 7 Design and Implementation
Chapter 7 Design and Implementation Chapter 7 Design and Implementation Slide 1 Topics covered Object-oriented design using the UML Design patterns Implementation issues Reuse Configuration management
More informationSoftware Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationGame Production: reuse
Game Production: reuse Fabiano Dalpiaz f.dalpiaz@uu.nl 1 Outline Lecture contents 1. Introduction to software reuse 2. Patterns 3. Application frameworks 4. Software product lines 5. Commercial-off-the-shelf
More informationComponent-based software engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1
Component-based software engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1 Objectives To explain that CBSE is concerned with developing standardised components and
More informationSoftware Engineering Chap.7 - Design and Implementation
Software Engineering Chap.7 - Design and Implementation Simão Melo de Sousa RELEASE (UBI), LIACC (Porto), CCTC (Minho) Computer Science Department University of Beira Interior, Portugal Eng.Info./TSI,
More informationDesign and Implementa3on
Software Engineering Design and Implementa3on 1 Design and implementation Software design and implementation is the stage in the software engineering process at which an executable software system is developed.
More informationSoftware Reuse Techniques
DCC / ICEx / UFMG Software Reuse Techniques Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Overview of Reuse Techniques Frameworks Design Patterns Configurable Applications Architecture Patterns
More informationIntroduction to Software Reuse
DCC / ICEx / UFMG Introduction to Software Reuse Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Software Reuse The use of existing software or software knowledge to build new software In the last
More informationChapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design
More informationChapter 6 Architectural Design. Chapter 6 Architectural design
Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying
More informationSOFTWARE ARCHITECTURE & DESIGN INTRODUCTION
SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION http://www.tutorialspoint.com/software_architecture_design/introduction.htm Copyright tutorialspoint.com The architecture of a system describes its major components,
More informationLecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationDistributed systems. Distributed Systems Architectures. System types. Objectives. Distributed system characteristics.
Distributed systems Distributed Systems Architectures Virtually all large computer-based systems are now distributed systems. Information processing is distributed over several computers rather than confined
More informationCMSC 435: Software Engineering Section 0201
CMSC 435: Software Engineering Section 0201 Atif M. Memon (atif@cs.umd.edu) 4115 A.V.Williams building Phone: 301-405-3071 Office hours Tu.Th. (11:00am-1:00pm) Don t wait, don t hesitate, do communicate!!
More informationUML and Objectorientation. Kristian Sandahl
UML and Objectorientation Kristian Sandahl 2 Maintenance Requirements Validate Requirements, Verify Specification cceptance Test (Release testing) System Design (rchitecture, High-level Design) Verify
More informationEPL603 Topics in Software Engineering
Lecture 4 - Software Reuse EPL603 Topics in Software Engineering Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740 Topics covered Software reuse The
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationSoftware Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software
Software Engineering - I An Introduction to Software Construction Techniques for Industrial Strength Software Chapter 9 Introduction to Design Patterns Copy Rights Virtual University of Pakistan 1 Design
More informationTopics in Object-Oriented Design Patterns
Software design Topics in Object-Oriented Design Patterns Material mainly from the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; slides originally by Spiros Mancoridis;
More informationΗΜΥ 317 Τεχνολογία Υπολογισμού
ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΕΙΣ 16-17: Component-Based Software Engineering ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software
More informationChapter 17 - Component-based software engineering. Chapter 17 So-ware reuse
Chapter 17 - Component-based software engineering 1 Topics covered ² Components and component models ² CBSE processes ² Component composition 2 Component-based development ² Component-based software engineering
More informationDesign Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1
What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely
More informationAspect-oriented Software Development. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 1
Aspect-oriented Software Development Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 1 Objectives To explain the principle of separation of concerns in software development To
More informationVerification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should
More informationAspect oriented Software Development. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 1
Aspect oriented Software Development Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 32 Slide 1 Objectives To explain the principle of separation of concerns in software development To
More information5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered
Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationChapter 6 Architectural Design
Chapter 6 Architectural Design Chapter 6 Architectural Design Slide 1 Topics covered The WHAT and WHY of architectural design Architectural design decisions Architectural views/perspectives Architectural
More informationDistributed Systems Architectures. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1
Distributed Systems Architectures Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1 Objectives To explain the advantages and disadvantages of different distributed systems architectures
More informationData ownership within governance: getting it right
Data ownership within governance: getting it right Control your data An Experian white paper Data Ownership within Governance : Getting it right - 1 Table of contents 1. Introduction 03 2. Why is data
More informationArchitectural Design. Architectural Design. Software Architecture. Architectural Models
Architectural Design Architectural Design Chapter 6 Architectural Design: -the design the desig process for identifying: - the subsystems making up a system and - the relationships between the subsystems
More informationDistributed Systems Architectures. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1
Distributed Systems Architectures Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 12 Slide 1 Objectives To explain the advantages and disadvantages of different distributed systems architectures
More informationSYLLABUS CHAPTER - 1 [SOFTWARE REUSE SUCCESS FACTORS] Reuse Driven Software Engineering is a Business
Contents i UNIT - I UNIT - II UNIT - III CHAPTER - 1 [SOFTWARE REUSE SUCCESS FACTORS] Software Reuse Success Factors. CHAPTER - 2 [REUSE-DRIVEN SOFTWARE ENGINEERING IS A BUSINESS] Reuse Driven Software
More informationUCSD Extension. Fundamentals of Web Services. Instructor: John Pantone. 2007, Objectech Corporation. All rights reserved
UCSD Extension Fundamentals of Web Services Instructor: John Pantone 1 Web Services Are: self-contained modular distributed dynamic Can be described published located invoked Over a network 2 Web Services
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationEngr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Software Design and Architecture Software Design Software design is a process of problem-solving
More informationHow to Harvest Reusable Components in Existing Software. Nikolai Mansurov Chief Scientist & Architect
How to Harvest Reusable Components in Existing Software Nikolai Mansurov Chief Scientist & Architect Overview Introduction Reuse, Architecture and MDA Option Analysis for Reengineering (OAR) Architecture
More informationVariability Implementation Techniques for Platforms and Services (Interim)
Engineering Virtual Domain-Specific Service Platforms Specific Targeted Research Project: FP7-ICT-2009-5 / 257483 Variability Implementation Techniques for Platforms and Services (Interim) Abstract Creating
More informationCSCU9T4: Managing Information
CSCU9T4: Managing Information CSCU9T4 Spring 2016 1 The Module Module co-ordinator: Dr Gabriela Ochoa Lectures by: Prof Leslie Smith (l.s.smith@cs.stir.ac.uk) and Dr Nadarajen Veerapen (nve@cs.stir.ac.uk)
More informationAn Introduction to Software Architecture By David Garlan & Mary Shaw 94
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion An Introduction to
More informationDesign Patterns Design patterns advantages:
Design Patterns Designing object-oriented software is hard, and designing reusable object oriented software is even harder. You must find pertinent objects factor them into classes at the right granularity
More informationSlide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D
Slide 1 Design Patterns Prof. Mirco Tribastone, Ph.D. 22.11.2011 Introduction Slide 2 Basic Idea The same (well-established) schema can be reused as a solution to similar problems. Muster Abstraktion Anwendung
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationReview Software Engineering October, 7, Adrian Iftene
Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)
More informationSoftware testing. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1
Software testing Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 23 Slide 1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationComponent-based Architecture Buy, don t build Fred Broks
Component-based Architecture Buy, don t build Fred Broks 1. Why use components?... 2 2. What are software components?... 3 3. Component-based Systems: A Reality!! [SEI reference]... 4 4. Major elements
More informationVerification and Validation. Assuring that a software system meets a user s needs. Verification vs Validation. The V & V Process
Verification and Validation Assuring that a software system meets a user s needs Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 19,20 Slide 1
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationCOSC 3351 Software Design. Design Patterns Behavioral Patterns (I)
COSC 3351 Software Design Design Patterns Behavioral Patterns (I) Spring 2008 Purpose Creational Structural Behavioral Scope Class Factory Method Adapter(class) Interpreter Template Method Object Abstract
More informationCS 307: Software Engineering. Lecture 10: Software Design and Architecture
CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra 2017 Dr. Jeffrey A. Turkstra 1 Announcements Discuss your product backlog in person or via email by Today Office
More informationPatterns. Giovanni Sakti. in Software Engineering. Starqle
Patterns in Software Engineering Giovanni Sakti Starqle What is Patterns? Patterns Patterns describes a problem, which occurs over and over again in our environment and then desribes the core of the solution
More informationCHAPTER 9 DESIGN ENGINEERING. Overview
CHAPTER 9 DESIGN ENGINEERING Overview A software design is a meaningful engineering representation of some software product that is to be built. Designers must strive to acquire a repertoire of alternative
More informationEnterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions Chapter 1: Solving Integration Problems Using Patterns 2 Introduction The Need for Integration Integration Challenges
More informationArchitectural Blueprint The 4+1 View Model of Software Architecture. Philippe Kruchten
Architectural Blueprint The 4+1 View Model of Software Architecture Philippe Kruchten Model What is a model? simplified abstract representation information exchange standardization principals (involved)
More informationDescribing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms?
Describing the architecture: Creating and Using Architectural Description Languages (ADLs): What are the attributes and R-forms? CIS 8690 Enterprise Architectures Duane Truex, 2013 Cognitive Map of 8090
More informationSecond. Incremental development model
3 rd Stage Lecture time: 8:30 AM-2:30 PM Instructor: Ali Kadhum AL-Quraby Lecture No. : 4 Subject: Software Engineering Class room no.: Department of computer science Second. Incremental development model
More informationChapter 32. Aspect-Oriented Software Development (AOSD) Ian Sommerville 2006 Software Engineering. Chapter 32 Slide 1
Chapter 32 Aspect-Oriented Software Development (AOSD) Ian Sommerville 2006 Software Engineering. Chapter 32 Slide 1 Objectives To explain the principle of separation of concerns in software development
More informationCSC207H: Software Design Lecture 6
CSC207H: Software Design Lecture 6 Wael Aboelsaadat wael@cs.toronto.edu http://ccnet.utoronto.ca/20075/csc207h1y/ Office: BA 4261 Office hours: R 5-7 Acknowledgement: These slides are based on material
More information1) Software Engineering
1) Software Engineering a) Software: Programs, documentation and configuration data which is needed to make programs operate correctly. i) Two types of Software Products: (1) Generic Products: Eg: word
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationExamples. Object Orientated Analysis and Design. Benjamin Kenwright
Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision
More informationSOFTWARE ENGINEERING DECEMBER. Q2a. What are the key challenges being faced by software engineering?
Q2a. What are the key challenges being faced by software engineering? Ans 2a. The key challenges facing software engineering are: 1. Coping with legacy systems, coping with increasing diversity and coping
More informationChapter 8, Object Design: Reusing Pattern Solutions
Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: Reusing Pattern Solutions Application Objects and Solution Objects Application objects, also called domain objects,
More informationReusable General Component in Unknown Domain
66 Reusable General Component in Unknown Domain Dr. Buthainah F. AL-Dulaimi Amer Abdulmejeed Abdurehman Computer Department/College of Education for Women/University of Baghdad Abstract: Component reuse
More informationEstablishing the overall structure of a software system
Architectural Design Establishing the overall structure of a software system Ian Sommerville 1995 Software Engineering, 5th edition. Chapter 13 Slide 1 Objectives To introduce architectural design and
More informationCompositional Model Based Software Development
Compositional Model Based Software Development Prof. Dr. Bernhard Rumpe http://www.se-rwth.de/ Seite 2 Our Working Groups and Topics Automotive / Robotics Autonomous driving Functional architecture Variability
More informationDesign Patterns. Observations. Electrical Engineering Patterns. Mechanical Engineering Patterns
Introduction o to Patterns and Design Patterns Dept. of Computer Science Baylor University Some slides adapted from slides by R. France and B. Tekinerdogan Observations Engineering=Problem Solving Many
More informationDay 1 summary for day 2. Addison, TX
Technical Interoperability Day 1 summary for day 2 April 12, 2007 Addison, TX Overview Summary of day 1 Top 5 issues Other topics discussed Issues for the future (day 2) Main Issues (1) Title: Adopt /
More informationSoftware Prototyping Animating and demonstrating system requirements. Uses of System Prototypes. Prototyping Benefits
Software Prototyping Animating and demonstrating requirements Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 8 Slide 1 Uses of System Prototypes
More informationReuse in Object Oriented Programming
DCC / ICEx / UFMG Reuse in Object Oriented Programming Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Overview of Reuse Techniques Frameworks Design Patterns Configurable Applications Architecture
More informationLesson 06. Requirement Engineering Processes
Lesson 06 Requirement Engineering Processes W.C.Uduwela Department of Mathematics and Computer Science Objectives To describe the principal requirements engineering activities and their relationships To
More informationLecture 15 Software Testing
Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered
More informationCAS 703 Software Design
Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Acknowledgments: Material based on Software by Tao et al. (Chapters 9 and 10) (SOA) 1 Interaction
More informationEnabling efficiency through Data Governance: a phased approach
Enabling efficiency through Data Governance: a phased approach Transform your process efficiency, decision-making, and customer engagement by improving data accuracy An Experian white paper Enabling efficiency
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationLegacy Systems. Older software systems that remain vital to an organisation. Legacy systems. Legacy system replacement
Legacy Systems Older software systems that remain vital to an organisation Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapters 26,27,28 Slide 1 Legacy
More informationLecture 8: Use Case -Driven Design. Where UML fits in
Lecture 8: Use Case -Driven Design The Role of UML in the Software Process E.g. ICONIX Domain Models Use Cases 2008 Steve Easterbrook. This presentation is available free for non-commercial use with attribution
More informationPREPARE FOR TAKE OFF. Accelerate your organisation s journey to the Cloud.
PREPARE FOR TAKE OFF Accelerate your organisation s journey to the Cloud. cloud. Contents Introduction Program & Governance BJSS Cloud Readiness Assessment: Intro Platforms & Development BJSS Cloud Readiness
More informationLecture 19: Introduction to Design Patterns
Lecture 19: Introduction to Design Patterns Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationASPECT GENERATOR. Audit Trail WEAVER. Aspect Editor. Weaving Strategies Editor. Model Editor. Mapping. Instructions. Original Model (XMI)
Tool Support for Aspect-Oriented Design Francois Mekerke 1, Geri Georg 2, Robert France 3, and Roger Alexander 3 1 Ecole Nationale Superieure des Etudes et Techniques d'armement, Brest, France mekerkfr@ensieta.fr
More informationSpecifying and Prototyping
Contents Specifying and Prototyping M. EVREN KIYMAÇ 2008639030 What is Specifying? Gathering Specifications Specifying Approach & Waterfall Model What is Prototyping? Uses of Prototypes Prototyping Process
More informationVO Software Engineering
Administrative Issues Univ.Prof. Dr. Peter Auer Chair for Information Technology Email: auer@unileoben.ac.at Lecture Thursday 10:15 11:45 Project Lab Montag 16:00 19:00 Literature Helmut Balzert, Lehrbuch
More informationSystem models Abstract descriptions of systems whose requirements are being analysed. System modelling. Structured methods
System models Abstract descriptions of systems whose requirements are being analysed Ian Sommerville 995/2000 (Modified by Spiros Mancoridis 999) Software Engineering, 6th edition. Chapter 7 Slide System
More informationSoftware specification and modelling. Requirements engineering
Software specification and modelling Requirements engineering Requirements engineering (RE) Requirements engineering is the process of establishing the services that a customer requires from a system and
More information18.1 Definitions and General OO Principles
Chapter 18: Design Patterns Design patterns are elegant, adaptable, and reusable solutions to everyday software development problems. Each pattern includes a description of a commonly occuring type of
More informationRequirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18
Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope
More informationSoftware re-engineering
Software re-engineering Reorganising and modifying existing software systems to make them more maintainable Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28 Slide 1 Objectives To explain
More informationRequirements Engineering
Requirements Engineering An introduction to requirements engineering Gerald Kotonya and Ian Sommerville G. Kotonya and I. Sommerville 1998 Slide 1 Objectives To introduce the notion of system requirements
More informationHigh-Fidelity analysis of software systems
High-Fidelity of software systems Dr. Nikolai Mansourov Chief Technology Officer, KDM Analytics http://www.kdmanalytics.com 5 March 2007 Agenda 1. Motivation: of security properties of existing software
More informationArchitectural Documentation 1
Architectural Documentation Architectural Documentation 1 The Purpose of Architectural Documentation The documentation shall give the reader good understanding of the application's architecture and design.
More information