Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family: Part 1 David Weiss

Slides:



Advertisements
Similar presentations
Dr. Rogelio Dávila Pérez
Advertisements

Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Software Systems.
Object-Oriented Analysis and Design
Software Architecture for DSD DSD Team. Overview What is software architecture and why is it so important? The role of architecture in determining system.
From Module Decomposition to Interface Specification Software Architecture Part 2.
Software Architecture for DSD
Architecture is More Than Just Meeting Requirements Ron Olaski SE510 Fall 2003.
Chapter 6 Database Design
File Systems and Databases
Site Skin Structure Services Space plan Stuff Software Architecture and Software Architecture Patterns (1)
Software Requirements
Architectural Design Principles. Outline  Architectural level of design The design of the system in terms of components and connectors and their arrangements.
Objectives The key roles an architecture description plays in a software project. The key roles an architecture description plays in a software project.
Chapter 2 Database Environment Pearson Education © 2014.
Course Instructor: Aisha Azeem
CSC230 Software Design (Engineering)
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Architectural Design.
What is Software Architecture?
Database Environment 1.  Purpose of three-level database architecture.  Contents of external, conceptual, and internal levels.  Purpose of external/conceptual.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Engineering Design Resolution & Design Principles.
UML - Development Process 1 Software Development Process Using UML (2)
Chapter 6 System Engineering - Computer-based system - System engineering process - “Business process” engineering - Product engineering (Source: Pressman,
An Introduction to Software Architecture
ITEC 3220M Using and Designing Database Systems
Intro to Architecture – Page 1 of 22CSCI 4717 – Computer Architecture CSCI 4717/5717 Computer Architecture Topic: Introduction Reading: Chapter 1.
Software Requirements Engineering CSE 305 Lecture-2.
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
Approaching a Problem Where do we start? How do we proceed?
David Weiss Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family David Weiss
Systems Analysis and Design in a Changing World, 3rd Edition
1 Introduction to Software Engineering Lecture 1.
DataBase Management System What is DBMS Purpose of DBMS Data Abstraction Data Definition Language Data Manipulation Language Data Models Data Keys Relationships.
CPSC 372 John D. McGregor Module 3 Session 1 Architecture.
Database Environment Chapter 2. Data Independence Sometimes the way data are physically organized depends on the requirements of the application. Result:
CPSC 871 John D. McGregor Module 3 Session 1 Architecture.
SOFTWARE DESIGN. INTRODUCTION There are 3 distinct types of activities in design 1.External design 2.Architectural design 3.Detailed design Architectural.
1 Chapter 1 Introduction to Databases Transparencies.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
A modular metadata-driven statistical production system The case of price index production system at Statistics Finland Pekka Mäkelä, Mika Sirviö.
1 Software Design Lecture What’s Design It’s a representation of something that is to be built. i.e. design  implementation.
Oman College of Management and Technology Course – MM Topic 7 Production and Distribution of Multimedia Titles CS/MIS Department.
Basic Concepts and Definitions
Chapter 2 Database Environment.
CS223: Software Engineering Lecture 13: Software Architecture.
Software Product-Line Engineering: A Family- Based Software Development Process: Producing Members Of The Family David Weiss
WELCOME TO OUR PRESENTATION UNIFIED MODELING LANGUAGE (UML)
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
COMS 309 Weiss Spring 2010 Producing Products Software Product-Line Engineering: A Family- Based Software Development Process: Producing Members Of The.
Chapter 9 Architectural Design. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software.
Chapter 7: Modifiability
Distribution and components
Chapter 6 Database Design
Designing Software for Ease of Extension and Contraction
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Database System Concepts and Architecture.
Chapter 2 Database Environment Pearson Education © 2009.
Database Environment Transparencies
Design Model Like a Pyramid Component Level Design i n t e r f a c d s
Analysis models and design models
Database Systems Instructor Name: Lecture-3.
An Introduction to Software Architecture
Chapter 9 Architectural Design.
Chapter 6: Architectural Design
Presentation transcript:

Software Product-Line Engineering: A Family-Based Software Development Process: Designing The Family: Part 1 David Weiss

FAST Process A process for defining families and developing environments for generating family members –Find abstractions common to the family –Define a process for producing family members –Design a language for specifying family members –Generate software from specifications Family-oriented Abstraction, Specification, Translation COMS 309 Weiss Spring 2010 Design The Family2

Product Engineering Environment A FAST Process Domain Engineering Product Engineering Products Feedback Investment Payback COMS 309 Weiss Spring 2010 Design The Family3

The Domain Model Conceptual Framework –Family Definition Commonalities and Variabilities Among Family Members Common Terminology for the Family Decision Model –Economic Analysis –Product Line Architecture –Optional: Application Modeling Language (AML): Language for stating requirements Mechanism for generating products –Composer or Compiler (AML) COMS 309 Weiss Spring 2010 Design The Family4

The Conceptual Framework (1) Qualify The Domain –Is it economically viable? –Artifact: Economic Model Define The Family –What do members of the family have in common and how do they vary? –Artifact: The Commonality/Variability Analysis Define The Decision Model –What decisions must be made to identify a family member? –Artifact: The Decision Model Table COMS 309 Weiss Spring 2010 Design The Family5

The Conceptual Framework (2) Create The Architecture –What is a good modular structure and a good uses structure? –Artifacts: Module Guide, Interface Specifications, Uses Relation Design The System Composition Mapping –What modules are needed for which decisions? –Artifacts: System Composition Mapping, Uses Relation Design The Product Engineering Environment –What are good mechanisms for using the decision model to produce products or to generate products from the AML? – Artifacts: Decision Model GUI, Generator or Compiler (AML) COMS 309 Weiss Spring 2010 Design The Family6

Interlude Architecture 7COMS 309 Weiss Spring 2010 Design The Family

What Is Architecture? “The art or science of building; esp. the art or practice of designing and building edifices for human use, taking both aesthetic and practical factors into account.” The Shorter Oxford English Dictionary, Fifth Edition, 2002 Merriam Webster Online Dictionary “In wider use, the term ‘architecture’ always means ‘unchanging deep structure.’ ” Stewart Brand, How Buildings Learn 8COMS 309 Weiss Spring 2010 Design The Family

Hagia Sophia, Istanbul COMS 309 Weiss Spring 2010 Design The Family9

Built COMS 309 Weiss Spring 2010 Design The Family10

Designers: Anthemius of Tralles and Isidorus of Miletus (Mathematicians, Engineers, Architects) COMS 309 Weiss Spring 2010 Design The Family11

Pendentives COMS 309 Weiss Spring 2010 Design The Family12

Hagia Sophia Interior. Four arches swing across the piers, linked by four pendentives. The apices of the arches and the pendentives support the circular base of the huge central dome. COMS 309 Weiss Spring 2010 Design The Family13

St. Paul’s Cathedral, London COMS 309 Weiss Spring 2010 Design The Family14

Architect: Sir Christopher Wren COMS 309 Weiss Spring 2010 Design The Family15

Built COMS 309 Weiss Spring 2010 Design The Family16

View From The Dome (1) COMS 309 Weiss Spring 2010 Design The Family17

View From The Dome (2) Millenium Bridge COMS 309 Weiss Spring 2010 Design The Family18

How Did They Know It Would Stay Up? COMS 309 Weiss Spring 2010 Design The Family19

Buckling Load B ~ ET/R T= Thickness R= Radius E = Elastic Modulus Assumptions 1.Spherical 2.Isotropic - identical properties at each point T R How Did They Know It Would Stay Up? Prototypes Theoretical Models COMS 309 Weiss Spring 2010 Design The Family20

Attributes Of An Admired Architecture Distinctiveness (Istanbul and London landmarks) Beauty Utility (used every day) Persistence (1500 years and more!!) Features that delight (whispering gallery, dome view) Maintainable Safe Buildable (safe intermediate states, affordable) Different structures for different purposes (load bearing, interior layout, building services, …) COMS 309 Weiss Spring 2010 Design The Family21

What is Software Architecture? Literally Hundreds of definitions Architecture is focused on –Partitioning the whole into parts –Specifying the relations among the parts –Satisfying Requirements Functional Requirements –End User Features … Other Engineering Requirements –Performance & Scalability, Reliability & Availability … COMS 309 Weiss Spring 2010 Design The Family22

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. "Externally visible” properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Software Architecture in Practice (2nd edition), (Bass, Clements, Kazman; Addison-Wesley 2003 COMS 309 Weiss Spring 2010 Design The Family23

Structure (View) A structure is a binary relation –Set of ordered pairs {(a,b), (c,d), (b,a), (c,e)} Defining a structure –Define the set of elements a,b,c,d,e –Define the relation Enumeration Rule Example: connected graph –Elements: nodes in the graph: a,b,c,d,e,f,g –Relation: “is connected to” {(a,b), (a,c), (b,d), (b,f), (f,e), (c.g)} COMS 309 Weiss Spring 2010 Design The Family24

a b c d e f g COMS 309 Weiss Spring 2010 Design The Family25

Structures and Models Every structure (view) should have a model associated with it Every model should help answer questions about the products –Questions are driven by the concern(s) associated with the view What is the buckling load? –Typical questions How much does it cost to make a particular type of change? How does performance vary with load on the product? What is the expected availability? COMS 309 Weiss Spring 2010 Design The Family26

Architectural Structures There are many stakeholders in the architecture of a software system – individuals or groups who have an interest in products built using the architecture. Product Management System Engineering Architects Software Development System Verification Information Development Project Management R&D Management Professional Services Services COMS 309 Weiss Spring 2010 Design The Family27

Architectural Structures Different Stakeholders have Different Concerns: Some Examples Product Management –How can I explain this architecture to customers, in a way that “sells” it to them? –What product variations are supported by the architecture? System Engineering –What functionality does a product built using this architecture offer to its users? –How are the product requirements embodied in the software? Architects –What changes may be needed in the software in the future, and what changes are likely and need to be especially easy to make in the future? Software Development, –What implementation constraints must I satisfy when I implement a module? –What technologies and standards are used to implement the modules defined by the architecture? COMS 309 Weiss Spring 2010 Design The Family28

Key Architectural Structures Module Structure –Explains the principles used to design the information hiding structure of the architecture, and shows how responsibilities are allocated among the major modules. Uses Structure –Describes the allowed “uses” relationships between modules and limits what other modules the implementer of a module may use. Process Structure –Defines the distinct processes in the system; Specifies the module(s) that make up the process, synchronization between processes … Module Interface Specs –Define Services Provided and Services Needed –Define syntax and semantics for accessing services –Define data types, program effects, … –Define test cases –Record design decisions and implementation notes COMS 309 Weiss Spring 2010 Design The Family29

Modules COMS 309 Weiss Spring 2010 Design The Family

“... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.” Edsger W. Dijkstra On Program Families COMS 309 Weiss Spring 2010 Design The Family

“... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.” Edsger W. Dijkstra On Program Families If you can modify it, you understand it. COMS 309 Weiss Spring 2010 Design The Family

Modules Module: Work assignment for a developer or small team of developers Concept explored and extended by David Parnas and others starting around 1970 Goals of modularization –Manage complexity by separating concerns –Make the system easier to: Understand Integrate and build Maintain (change) Test Verify Develop by a team –Free modules from product specific dependencies COMS 309 Weiss Spring 2010 Design The Family33

Modularization Criteria Possible ways to organize a system into modules –Functional: each module is a function –Steps in processing: each module is one step in a chain of processing –Information hiding: each module hides a design decision Information hiding principle –Independently-changeable information, such as design decisions, should be hidden in independently-changeable modules –Changes to module implementations are hidden behind well- defined interfaces that are stable over time –Secret: decision that’s hidden in a module COMS 309 Weiss Spring 2010 Design The Family34

Typical secrets SecretTypical Change How to monitor a sensorNew more reliable sensor, higher resolution sensor How to control a deviceFaster, “larger”, version of device Platform characteristicsFaster processor, multi- processor, larger memory How to control a displayReorganization of screen real- estate, look and feel How to exchange dataProtocol change Database physical structureFields added, faster access needed, field sizes change AlgorithmDifferent time-space trade-off needed, more accurate algorithm invented Representation of system entities such as jobs and users Change in performance requirements More system entities COMS 309 Weiss Spring 2010 Design The Family35

Describing Modules What’s the secret? –Example: Conditions under which outputs are produced Module: Behavior Hiding Module –Example: How to use services provided by other modules to obtain averaged wind speed data and transmit it at a fixed period. Module: Message Generation Module What service(s) are provided by the module? –Example: Periodically retrieve data from the Data Banker and transmit it. Module: Message Generation Module COMS 309 Weiss Spring 2010 Design The Family36

Organizing Secrets Hierarchically Environment characteristics –External device characteristics (How to monitor sensors) –External system characteristics (Protocol needed to communicate externally) –Platform characteristics Platform specific services Resource allocation algorithms –Thread Management –Processor scheduling –Memory allocation Required behavior –Conditions under which outputs are produced (How often to send a message) Software design decisions –How to store data –Computational algorithms (Averaging?) COMS 309 Weiss Spring 2010 Design The Family37

The Module Hierarchy A is a submodule of B means that A’s secret is a subsecret of B’s secret Example –Device Interface: How to monitor and control devices –Sensor Device Driver (How to monitor sensor) –Transmitter Device Driver (How to control transmitter) COMS 309 Weiss Spring 2010 Design The Family38

The Module Hierarchy: Questions That The Structure Answers How do I assign work to developers? –Testers? What changes will be easy to accommodate? –Hard to accommodate? What are the abstractions used in the system? –How can I understand the system? COMS 309 Weiss Spring 2010 Design The Family39

COMS 309 Weiss Spring 2010 Design The Family40 Sensor Device FWS Behavior HidingDevice InterfaceSoftware Design Hiding Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor FWS Module Hierarchy Graphical View

COMS 309 Weiss Spring 2010 Design The Family41

The Module Guide Textual description of the module hierarchy Each module described by its secret COMS 309 Weiss Spring 2010 Design The Family42

Excerpts From The FWS Module Guide (1) 1.Behavior Hiding Modules The behavior hiding modules include programs that need to be changed if the required outputs from a FWS and the conditions under which they are produced are changed. Its secret is when (under what conditions) to produce which outputs. Programs in the behavior hiding module use programs in the Device Interface module to produce outputs and to read inputs. 1.1 Controller Service Provide the main program that initializes a FWS. Secret How to use services provided by other modules to start and maintain the proper operation of a FWS. Associated variabilities and parameters of variation None COMS 309 Weiss Spring 2010 Design The Family43

Excerpts From The FWS Module Guide (2) 2.Device Interface Modules The device interface modules consist of those programs that need to be changed if the input from hardware devices to FWSs or the output to hardware devices from FWSs change. The secret of the device interface modules is the interfaces between FWSs and the devices that produce its inputs and that use its output. 2.1.Sensor Device Driver Service Provide access to the wind speed sensors. There may be a submodule for each sensor type. Secret How to communicate with, e.g., read values from, the sensor hardware. Associated variabilities and parameters of variation V7., the wind speed sensor hardware. Note This module hides the boundary between the FWS domain and the sensors domain. The boundary is formed by an abstract interface that is a standard for all wind speed sensors. Programs in this module use the abstract interface to read the values from the sensors. COMS 309 Weiss Spring 2010 Design The Family44

Abstraction Abstraction: many-to-one mapping –Not “vague” –Not mathematical –Not high-level Model common aspects, but not all aspects –Device abstraction: abstract away from details of control sequences –Data abstraction: abstract away from data representation –… One model, implementable many ways –Commonality and variability Levels of abstraction?? COMS 309 Weiss Spring 2010 Design The Family45

Different views of information hiding modules A set of programs and shared data Work Assignment: Design and implement the programs and the data structures that those programs share Public Interface: The subset of the module’s programs that are visible, forming an abstract interface for the module’s users. The programs may include data types, signals, exceptions, and other devices that the implementers employ to reflect the assumptions that the module’s users are allowed to make about the module. Secret: How the programs are implemented, what the internal representation of the data is, and what internal programs are needed as part of the implementation. An abstract interface and its implementation Work assignment: Design and implement the interface. The interface is abstract in that there are many possible implementations of it. Public Interface: A set of programs that provide the services offered by the module to its users. The programs may include data types, signals, exceptions, and other devices that the implementers employ to reflect the assumptions that the module’s users are allowed to make about the module. Secret: What programs and data structures are hidden behind the interface and how they are implemented. COMS 309 Weiss Spring 2010 Design The Family46

Different views of information hiding modules A state machine Work assignment: Implement the state transition function of the state machine. Public Interface: Typically, a set of programs that provide ways to read the state of the module and to cause the module to transition from one state to another. Secret: How the state transition function is implemented, i.e., what programs and data structures are used to implement it. A class Work assignment: Design and implement the public and private methods and the data structures needed to implement the module. Public Interface: The public methods and data of the class. Secret: How the methods are implemented, what the private methods are, and what data structures are used by the methods but do not appear in the interface. COMS 309 Weiss Spring 2010 Design The Family47

Different views of information hiding modules An abstract data type Work assignment: Design and implement the data structure used to hold the data for variables of the type, and the operations that may be performed on the data. Public Interface: The operations that may be performed on the data type, including functions that read and change the value of the data. Secret: What the representation of the data structure is and how the operations are implemented. An abstraction Work assignment: Design and implement instances of the many-to-one mapping that constitutes the abstraction. Public Interface: The range of the many-to-one mapping, i.e., those programs and data that embody the services offered by the abstraction to its users. One may think of these as the common parts of the abstraction. Secret: How the details of the mapping are implemented so that the common parts of the abstraction remain fixed for different instances. COMS 309 Weiss Spring 2010 Design The Family48

Different views of information hiding modules A collection of macros and preprocessor directives Work assignment: Design and implement the macros and directives. Public Interface: The set of macros and directives that the developers of other modules may use. Secret: How the macros are implemented. Note design time binding. A black box Work assignment: Design and implement the external appearance and the internal implementation. Public Interface: The buttons and dials that the users can use. Secret: How the box is built. COMS 309 Weiss Spring 2010 Design The Family49

Information hiding modules as abstractions Module defines an abstraction (many-to-one mapping) –Common part is what’s revealed to module’s users (the one) –Secret is how the module is implemented (the many) Services (capabilities) that the module provides allows module users to take advantage of the abstraction –Abstract data types: Users operate on the data without knowing its representation –GUI creation environments (VB): Users construct GUIs without knowing details of how to display –Protocols: Users send and receive data without knowing details of channel operation –Methods: Users invoke methods without knowing module’s algorithms COMS 309 Weiss Spring 2010 Design The Family50

Information Hiding Modules And Product Lines We want to be able to change the value of each variability independently Create a module for each variability –Secret of the module is how the variability is implemented There may be additional modules for other design decisions Example: Message Format Module –Secret: How to create a message in the correct format for transmission –Variability: MsgType (V2, P4) COMS 309 Weiss Spring 2010 Design The Family51

Architecture for the Product Line Purpose: Enable product generation through composition of modules, each module hiding a parameter of variation Apply information hiding to create a modular architecture –Each variability is the hidden decision of a module Guidance for constructing the modular structure Define interface specifications for each module Define a uses relation among programs that appear on module interfaces Define the process structure COMS 309 Weiss Spring 2010 Design The Family52

Summary Information hiding modules are work assignments that hide design decisions We organize information hiding modules into a module hierarchy, described in the module guide for the family In a product line, for each variability there is a module whose secret is how the variability is implemented Architecture is a set of structures, such as module structure, uses structure, process structure, plus interface specifications COMS 309 Weiss Spring 2010 Design The Family53

Terminology Family Product Line Conceptual Model Domain Engineering Domain Model Product Engineering (aka Application Engineering) Product Engineering Environment Decision Model Commonality/Variability Analysis System Composition Mapping Application Modeling Language Structure Module Secret Abstraction Module Hierarchy, Module Guide Uses Process COMS 309 Weiss Spring 2010 Design The Family54

Exercise 4: Modifying a Modular Structure: Part 1a Review the FWS Module Guide, answering the following questions. 1. For each module, is the module in an appropriate place in the hierarchy? If not, identify the misplaced module(s) and where they should be located. 1. Are there modules that are missing from the Module Guide? If so, what are they, what are their secrets, and where should they be placed in the hierarchy? COMS 309 Weiss Spring 2010 Design The Family55

Exercise 4: Modifying a Modular Structure: Part 1b Review the FWS Module Guide, answering the following questions. 3. For each variability, which module has the implementation of the variability as its secret? 4. Pick one module and describe the abstraction that it represents. Try to do this in one sentence. COMS 309 Weiss Spring 2010 Design The Family56

Exercise 4: Modifying a Modular Structure: Part 2 1.Propose a new module for the FWS that will be needed to implement a new variability for the FWS that you propose. State an appropriate secret for this module. Variability: Module (name and secret): COMS 309 Weiss Spring 2010 Design The Family57

2.Add your new module to the FWS Module Hierarchy Graphical View COMS 309 Weiss Spring 2010 Design The Family58 Sensor Device FWS Behavior HidingDevice InterfaceSoftware Design Hiding Transmitter Device Message Generation Message Format Averager Data Banker Sensor Monitor

3.Add your new module to the FWS Module Guide COMS 309 Weiss Spring 2010 Design The Family59 Section: Module Name: Service Secret Associated variabilities and parameters of variation: