1 / 40

Component Based Software Engineering

Introduction. Component Based Software Engineering. Software as a service. Traditional Software. On-Demand Utility. Plug In, Subscribe Pay-per-Use. Build Your Own. Introduction. What is this course about ? Software is a set of components, pattern design or services. Introduction.

Download Presentation

Component Based Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction Component Based Software Engineering

  2. Software as a service Traditional Software On-DemandUtility Plug In, SubscribePay-per-Use Build Your Own

  3. Introduction • What is this course about ? • Software is a set of components, pattern design or services

  4. Introduction • What is this course about ? • A journey in searching for the “holy grail” of software “integrated circuits”

  5. Advantage 1: Software construction Application Software construction vs. creation: application is developed as an assembly of “integrated circuits”

  6. Advantage 2: Reuse Application1 C1 C1 Application2 C1 Software “integrated circuits” are reusable entities It pays off to have as many applications that reuse an entity

  7. Advantage 3: Maintenance & Evolution C1new C1 Application update Maintenance and upgrading can be done by replacing parts, maybe even at runtime

  8. What are the “Entities” to compose ? • Functions • Modules • Objects • Components • Services • … 1960 1968: Douglas McIlroy: “Mass Produced Software Components” 1970 1980 1990 1998: Clemens Szyperski: “Component Software – Beyond Object Oriented Programming” 2000 2010

  9. Principles for reuse by composition • Key requirements for Black-Box reuse: • Abstraction: an “Entity” is known by its “interface” • Encapsulation: the “insides” of an “Entity” are not exposed to the outside

  10. Commonalities of Reusable Entities • All are blobs of code that can do something • All have interfaces that describe what they can do. • All live in a process somewhere. • All live to do the bidding of a client. • All support the concept of a client making requests by “invoking a method.” From [ACM Queue]

  11. Reusable Entities by Location and Environment From [ACM Queue]

  12. Reusable Entitiesmade more usable and more composable • Issues: • Interface description – what should contain a complete description ? • Composition – how are components glued together ? (do I have to write much code ?) • Discovery – where and how to find the component/service you need ? • Dynamic aspects – when to do discovery/selection/composition • Less stress on binary implementation – crossing platform/model boundaries

  13. Software engineering Software engineering is concerned with theories, methods and tools for professional software development

  14. What is software? • Computer programs and associated documentation • Software products may be • Generic - developed to be sold to a range of different customers • Bespoke (custom) - developed for a single customer according to their specification • Embedded • Built into hardware • Hard to change

  15. Software Applications 1. System software: such as compilers, editors, file management 2. Application software: stand-alone programs for specific needs. 3. Engineering/scientific software: such as automotive stress analysis, molecular biology, orbital dynamics etc 4. Embedded software resides within a product or system. (key pad control of a microwave oven, digital function of dashboard display in a car) 5. Product-line software focus on a limited marketplace to address mass consumer market. (word processing, graphics, database management) 6. WebApps (Web applications) network centric software :remote database and business applications. 7. AI software Robotics, expert system, pattern recognition game playing

  16. Software Engineering • Software Engineering is the science and art of • building significant software systems that are: • 1) on time • 2) on budget • 3) with acceptable performance • 4) with correct operation.

  17. What is a software process? • A set of activities whose goal is the development or evolution of software • Generic activities in all software processes are: • Specification - what the system should do and its development constraints • Development - production of the software system • Validation - checking that the software is what the customer wants • Evolution - changing the software in response to changing demands

  18. What is a software process model? • A simplified representation of a software process, presented from a specific perspective • Examples of process perspectives are • Workflow perspective - sequence of activities • Data-flow perspective - information flow • Role/action perspective - who does what • Waterfall • Evolutionary development • Formal transformation • Integration from reusable components

  19. Software Quality... • Usability • Users can learn it and fast and get their job done easily • Efficiency • It doesn’t waste resources such as CPU time and memory • Reliability • It does what it is required to do without failing • Maintainability • It can be easily changed • Reusability • Its parts can be used in other projects, so reprogramming is not needed

  20. Data Flow Model of a Car Assembly Unit Engine Store Door Store Chassis with Engine Partly Assembled Car Fit Wheels Fit Doors Paint and Test Car Fit Engine Assembled Car Chassis Store Wheel Store

  21. What is a Component? • Key characteristics of a component: • Higher-level of abstraction than objects • Communication between components is usually via messages • Non-context specific (the state of another component does not influence it unless that component is passed into it) • Encapsulated – you can not determine its implementation • A unit of independent deployment and versioning • Composable with other components • Written to a well-defined interface or contract

  22. Examples • NASA software • 25 software product ranged from 3000 to 112000 lines of source code • 7188 components classified into 4 classes • Component used without changes • Components reused with slight revisions less than 25% • Components reused with major revisions • Components reused with developing rom scratch

  23. Reusable Component Types • Application system reuse • The whole of an application system may be reused on a different machine. Usually referred to as program portability. • Sub-system reuse • Major sub-systems such as a pattern-matching system may be reused. • Modules or object reuse • The reusable component is a collection of functions or procedures. • Function reuse • The reusable component is a single function (method).

  24. C++ Class Templates template <class T> class Stack { public: Stack(int = 10) ; ~Stack() { delete [] stackPtr ; } int push(const T&); int pop(T&) ; int isEmpty()const { return top == -1 ; } int isFull() const { return top == size - 1 ; } private: int size ; // number of elements on Stack. int top ; T* stackPtr ; } ;

  25. C++ Function Templates #include <iostream> using namespace std ; //max returns the maximum of the two elements template <class T> T max(T a, T b) { return a > b ? a : b ; }

  26. C# components • The most commonly used components in .NET are the visual controls that you add to Windows Forms such as the Button Control (Windows Forms), ComboBox Control (Windows Forms), and so on. • Non-visual components include the Timer Control, SerialPort, and ServiceController among others.

  27. Software Components Design Patterns

  28. Design patterns • The reference for design patterns • “Gang of four” • Based on Erich Gamma’s Ph.D. thesis

  29. What is a design pattern? • A solution for a recurring problem in a large OOP system • “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 it the same way twice” • A pattern is the outline of a reusable solution to a general problem encountered in a particular context

  30. Design Patterns • Designis blue print or sketch of something so it can be defined as creation of something in mind • Pattern is defined as guideline or something that repeats • Design Pattern becomes creating something in mind that repeats or • capturing design ideas as a "pattern" to the problems.

  31. Example • Database normalization. • Normalization is a pattern (Core solution to database design) but what level of normalization needs (exact solution) depends on requirement and context.

  32. Types of design patterns • Design patterns can be (roughly) grouped into three categories: • Creational patterns • Constructing objects • Structural patterns • Controlling the structure of a class • Behavioral patterns • Deal with how the object behaves

  33. Creational Patterns • Patterns used to abstract the process of instantiating objects. • class-scoped patterns • uses inheritance to choose the class to be instantiated • Factory Method • object-scoped patterns • uses delegation • Abstract Factory • Builder • Prototype • Singleton

  34. Structural Patterns • concerned with how classes and objects are composed to form larger structures • Adapter • interface converter • Bridge • decouple abstraction from its implementation • Composite • compose objects into tree structures, treating all nodes uniformly • Decorator • attach additional responsibilities dynamically • Façade • provide a unified interface to a subsystem • Flyweight • using sharing to support a large number of fine-grained objects efficiently • Proxy • provide a surrogate for another object to control access

  35. Think of drawing/diagrammingeditors • Drawing/diagramming editors let users build complex diagrams out of simple components • The user can group components to form larger components... • ...which in turn can be grouped to form still larger components

  36. Adapter

  37. Proxy pattern

More Related