We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byRocio Coller
Modified over 2 years ago
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components
SE, CBSE, Hans van Vliet, © LEGO analogy Set of building blocks in different shapes and colors Can be combined in different ways Composition through small stubs in one and corresponding holes in another building block LEGO blocks are generic and easily composable LEGO can be combined with LEGO, not with Meccano
SE, CBSE, Hans van Vliet, © Why CBSE? CBSE increases quality, especially evolvability and maintainability CBSE increases productivity CBSE shortens development time
SE, CBSE, Hans van Vliet, © Component model Defines the types of building block, and the recipe for putting them together More precisely, a component model defines standards for: Properties individual components must satisfy Methods and mechanisms for composing components Consequently, a component has to conform to some component model
SE, CBSE, Hans van Vliet, © A software component: Implements some functionality Has explicit dependencies through provides and required interfaces Communicates through its interfaces only Has structure and behavior that conforms to a component model
SE, CBSE, Hans van Vliet, © A component technology Is the implementation of a component model, by means of: Standards and guidelines for the implementation and execution of software components Executable software that supports the implementation, assembly, deployment, execution of components Examples: EJB, COM+,.NET, CORBA
SE, CBSE, Hans van Vliet, © Component forms Component goes through different stages: development, packaging, distribution, deployment, execution Across these stages, components are represented in different forms: During development: UML, e.g. When packaging: in a.zip file, e.g. In the execution stage: blocks of code and data
SE, CBSE, Hans van Vliet, © Characterization of component forms
SE, CBSE, Hans van Vliet, © Component forms in different stages
SE, CBSE, Hans van Vliet, © Component specification vs component interface Specification describes properties to be realized: realization contract Interface describes how components interact: usage contract Different in scope as well: specification is about the component as a whole, while an interface might be about part of a component only
SE, CBSE, Hans van Vliet, © Hiding of component internals Black box: only specification is known Glass box: internals may be inspected, but not changed Grey box: part of the internals may be inspected, limited modification is allowed While box: component is open to inspection and modification
SE, CBSE, Hans van Vliet, © Managing quality in CBSE Who manages the quality: the component, or the execution platform Scope of management: per-collaboration, or system-wide
SE, CBSE, Hans van Vliet, © Quality management in CBSE
SE, CBSE, Hans van Vliet, © Managing quality in CBSE Approach A: left to the designers (e.g. when integrating COTS components) Approach B: model provides standardized facilities for managing qualities Approach C: component only addresses functionality, quality in surrounding container Approach D: similar to C, but container interacts with platform on quality issues
SE, CBSE, Hans van Vliet, © Common features of component models Infrastructure mechanisms, for binding, execution, etc Instantiation Binding (design time, compile time, …) Mechanisms for communication between components Discovery of components Announcement of component capabilities (interfaces) Development support Language independence Platform independence Analysis support Support for upgrading and extension Support for quality properties
SE, CBSE, Hans van Vliet, © Development process in CBSE Two separate development processes: Development of components Development of systems out of components Separate process to assess components
SE, CBSE, Hans van Vliet, © CBSE system development process Requirements: also considers availability of components (like in COTS) Analysis and design: very similar to what we normally do Implementation: less coding, focus on selection of components, provision of glue code Integration: largely automated Testing: verification of components is necessary Release: as in classical approaches Maintenance: replace components
SE, CBSE, Hans van Vliet, © Component assessment Find components Verify components Store components in repository
SE, CBSE, Hans van Vliet, © Component development process Components are intended for reuse Managing requirements is more difficult More effort required to develop reusable components More effort in documentation for consumers
SE, CBSE, Hans van Vliet, © Component development process Requirements: combination of top-down (from system) and bottom-up (generality) Analysis and design: generality is an issue, assumptions about system (use) must be made Implementation: largely determined by component technology Testing: extensive (no assumptions of usage!), and well-documented Release: not only executables, also metadata
SE, CBSE, Hans van Vliet, © Component maintenance Who is responsible: producer or consumer? Blame analysis: relation between manifestation of a fault and its cause, e.g. Component A requires more CPU time As a consequence, B does not complete in time As required by C, so C issues a time-out error to its user Analysis: goes from C to B to A to input of A Who does the analysis, if producers of A,B,C are different?
SE, CBSE, Hans van Vliet, © Architecture and CBSE Architecture-driven: top-down: components are identified as part of an architectural design Product line: family of similar products, with 1 architecture COTS-based: bottom-up, architecture is secondary to components found
SE, CBSE, Hans van Vliet, © Summary To enable composition, components must be compatible: achieved by component model Separation of development process for components from that of assembling systems out of components Architectural plan organizes how components fit together and meet quality requirements
Modeling Main issues: What do we want to build How do we write this down.
25 seconds left….. 24 seconds left….. 23 seconds left…..
Software Reusability Main issues: Why is reuse so difficult How to realize reuse.
1 15 Making the System Operational Lecture Activities of the Implementation and Support Phases Figure 15-1.
Business Transaction Management Software for Application Coordination 1 Business Processes and Coordination.
1 Chapter 10 Software Testing This chapter is extracted from Sommerville’s slides. Text book chapter 23 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
WEEK 1 You have 10 seconds to name…
Addition 1’s to
Slide 1 Testing Workflow Purpose l Purpose Verify the result from implementation by testing each build Plan the tests in each iteration Integration tests.
Component-Based Software Engineering and Software Assurance SSW-540, Unit 12.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 1 Configuration management l Managing the products of system change l Objectives.
Addition Facts = = =
Jeopardy Topic 1Topic Q 1Q 6Q 11Q 16Q 21 Q 2Q 7Q 12Q 17Q 22 Q 3Q 8Q 13Q 18Q 23 Q 4Q 9Q 14Q 19Q 24 Q 5Q 10Q 15Q 20Q 25 Final Jeopardy.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering 1.
Testing Components in the Context of a System CMSC 737 Fall 2006 Sharath Srinivas.
1 Copyright © 2005, Oracle. All rights reserved. Introducing the Java and Oracle Platforms.
©Ian Sommerville 2007Change Management Slide 1 Software change management.
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
DIVIDING INTEGERS 1. IF THE SIGNS ARE THE SAME THE ANSWER IS POSITIVE 2. IF THE SIGNS ARE DIFFERENT THE ANSWER IS NEGATIVE.
Global Analysis and Distributed Systems Software Architecture Lecture # 5-6.
We will resume in: 25 Minutes We will resume in: 24 Minutes.
Lecture 8: Testing, Verification and Validation Dr Valentina Plekhanova University of Sunderland, UK.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 32. Review Behavioral Patterns – Observer Pattern – Chain of command.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 8 Slide 1 Chapter 8 Software Prototyping.
1 Chapter 11 Software Evolution This chapter is extracted from Sommerville’s slides. Text book chapter 21 1.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
L6 - March 1, 2006copyright Thomas Pole , all rights reserved 1 Lecture 6: Software Packaging: Dynamically Integrable Components and Text Ch.
Software Engineering Module 1 -Components Teaching unit 3 – Advanced development Ernesto Damiani Free University of Bozen - Bolzano Lesson 2 – Components.
1 Service Oriented Architecture Reference Model An informal SOA Ontology.
INTRODUCTION TO SIMULATION WITH OMNET++ José Daniel García Sánchez ARCOS Group – University Carlos III of Madrid.
Cost as a Business Driver 1 John Brown C Eng MIEE mr_ Software Cost Estimation.
1 Copyright © 2010, Elsevier Inc. All rights Reserved Fig 2.1 Chapter 2.
User Interface Design Main issues: What is the user interface How to design a user interface.
From Model-based to Model-driven Design of User Interfaces.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
DATABASE SYSTEM CONCEPTS AND ARCHITECTURE CHAPTER 2 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 23 Slide 1 Software testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
1 Unified Modeling Language, Version 2.0 Chapter 2.
Chapter 2 The process Process, Methods, and Tools Software engineering is a layered technology.
Presented to: By: Date: Federal Aviation Administration Registry/Repository in a SOA Environment SOA Brown Bag #5 SWIM Team March 9, 2011.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14Slide 1 Chapter 14 Design with Reuse.
Component-Based Software Engineering (CBSE) Speaker: Jerry Gao Ph.D. San Jose State University URL:
BT Wholesale October Creating your own telephone network WHOLESALE CALLS LINE ASSOCIATED.
Lecture 6: Software Design (Part I) Dr Valentina Plekhanova University of Sunderland, UK
© 2016 SlidePlayer.com Inc. All rights reserved.