ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 3 Partially based on lecture notes written by Richard N. Taylor, André van der Hoek, Dan Frost, David Redmiles & Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

Topic 3Summer Today’s Lecture n Principles of software engineering n An introduction to requirements

Topic 3Summer Principles of Software Engineering n Deal with both process and product n Applicable throughout the lifecycle n Principles form the basis of methods, techniques, methodologies and tools n Principles become practice through methods and techniques –often methods and techniques are packaged in a methodology –methodologies can be enforced by tools

Topic 3Summer Relationship between Principles, Methods, Methodologies and Tools

Topic 3Summer Recurring, Fundamental Principles of S/w Engineering n Rigor and formality n Separation of concerns n Modularity n Abstraction n Anticipation of change n Generality n Incrementality These principles apply both to product and to process.

Topic 3Summer Rigor and Formality n Rigor: to be exact or strictly precise n Rigor is a necessary complement to creativity –Creativity often leads to imprecision and inaccuracy –Thus, it must be practiced systematically n Rigor helps.. –…understandability, Improve reliability, facilitates assessment, control cost, increase confidence in products n Formality is the highest degree of rigor –mathematically sound –Often used for mission critical systems

Topic 3Summer Rigor & Formality (2) n Process example: Rigorous documentation of development steps helps project management and assessment of timeliness n Product examples: –Mathematical (formal) analysis of program correctness –Systematic (rigorous) test data derivation

Topic 3Summer Separation of Concerns n To dominate complexity, separate the issues to concentrate on one at a time n Trying to do too many things at the same time often leads to mistakes –Software development is comprised of many parallel tasks, goals, and responsibilities –Software development cannot tolerate mistakes n "Divide & conquer" n Allows concentration on individual aspects –product features: functions, reliability, efficiency, environment, user interface, etc. –process features: development environment, team organization, scheduling, methods, –economics and management n Separation of Concerns helps… –…divide a problem into parts that can be dealt with separately –…create an understanding of how the parts depend on/relate to each other

Topic 3Summer Separation of Concerns (2) n Process: –Go through phases one after the other (as in waterfall) –Management: separation of responsibilities, expertise –Requirements, design, implementation, testing, … n Product –Qualities Efficiency and user friendliness

Topic 3Summer Modularity n A complex system may be divided into simpler pieces called modules n Permits separation of concerns: –deal with each module in isolation (ignore rest of system) –deal with overall system (ignore module details) n Promotes reuse n Promotes understandability n Modules should have high cohesion and low coupling –high cohesion: all elements within are strongly related module understandable as a meaningful unit –low coupling: modules are largely independent of each other

Topic 3Summer Modularity Big Small

Topic 3Summer Coupling VERSUS

Topic 3Summer Cohesion VERSUS

Topic 3Summer Abstraction n Identify the important aspects of a phenomenon and ignore its details n Separation into individual, logical parts –Relevant versus irrelevant details Use relevant details to solve task at hand Ignore irrelevant details n The type of abstraction to apply depends on purpose n Example : the user interface of a watch (its buttons) abstracts from the watch's internals for the purpose of setting time; other abstractions needed to support repair

Topic 3Summer Abstraction Big Abstraction Details

Topic 3Summer Anticipation of Change n Constant change is inevitable in large-scale software systems –software repair & error elimination –evolution of the application –evolution of the social order n Not anticipating change often leads to high cost and unmanageable software –Software development deals with inherently changing requirements –Software development can tolerate neither high cost nor unmanageable software n What to do? –Identify likely changes and plan for change software requirements usually not entirely understood users and environments change also affects management of software process n Anticipation of change helps to… –…create a software infrastructure that absorbs changes easily –…enhance reusability of components –…control cost in the long run

Topic 3Summer Generality n Focus on discovering more general problem than the one at hand –fosters potential reuse –facilitates identification of OTS solution n Not generalizing often leads to continuous redevelopment of similar solutions –Software development involves building many similar kinds of software (components) n Trade-offs between initial costs vs. reuse savings n Generality leads to… –…increased reusability –…increased reliability –…faster development –…reduced cost

Topic 3Summer Incrementality n Process proceeds in a stepwise fashion (increments) n Delivering a large product as a whole, and in one shot, often leads to dissatisfaction and a product that is “not quite right” –Software development typically delivers one final product –Results in “not what the customer wanted” n Identify and “deliver” early subsets to gain early feedback –fosters controlled evolution n Incremental concentration on required qualities n Intermediate deliverables may be prototypes n Incrementality leads to… –…the development of better products –…early identification of problems –…an increase in customer satisfaction Active involvement of customer

Topic 3Summer Provided Interface Implementation Required Interface A Good Separation of Concerns, 1 Abstraction through the use of provided/required interfaces Modularity through the use of components Low coupling through the use of hierarchies High cohesion through the use of coherent implementations Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface

Topic 3Summer Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface A Good Separation of Concerns, 2 Abstraction through the use of provided/required interfaces Modularity through the use of components Low coupling through the use of a central “blackboard” High cohesion through the use of coherent implementations Implementation Provided Interface

Topic 3Summer Benefit 1: Anticipating Change Separating concerns allows for anticipation of change Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Implementation Provided Interface

Topic 3Summer Benefit 2: Promoting Generality Separating concerns promotes generality Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface

Topic 3Summer Benefit 3: Facilitating Incrementality Separating concerns facilitates incrementality Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface Implementation Provided Interface Implementation Required Interface Provided Interface Implementation Required Interface

Topic 3Summer ICS 52 Life Cycle Requirements phase Verify Design phase Verify Implementation phase Test Testing phase Verify

Topic 3Summer ICS 52 Software Life Cycle n Requirements specification –Interview customer (TA) –Focus on “what”, not “how” n Architectural and module design –Based on provided “official” requirements specification –Focus on interfaces n Implementation –Based on provided “official” design –Focus on good implementation techniques n Testing –Based on provided “official” implementation –Focus on fault coverage and discovery

Topic 3Summer Requirements Phase n Terminology –Requirements analysis/engineering Activity of unearthing a customer’s needs –Requirements specification Document describing a customer’s needs n Note: requirements address what a customer needs, not what a customer wants –A customer often does not know what they want or how to express it –Time-lag between initial desire and future need –Long and arduous, sometimes educational, process

Topic 3Summer Requirements Analysis n System engineering versus software engineering –What role does software play within the full solution? –Trend: software is everywhere –Even in computer chips n Contract model versus participatory design –Contract: carefully specify requirements, then contract out the development –Participatory: customers, users, and software development staff work together throughout the life cycle

Topic 3Summer Techniques for Requirements Analysis n Interview customer n Create use cases/scenarios n Prototype solutions n Observe customer n Identify important objects/roles/functions n Perform research n Construct glossaries n Question yourself Use the principles

Topic 3Summer Why have a Requirements Specification (the Document)? n Contract –Serve as the fundamental reference point between builder and buyer/user/"consumer " n Defines capabilities to be provided without saying how they should be provided –Defines the “what” –Does not define the “how” n Define constraints and environmental requirements on the software to guide the implementers –e.g. performance, platforms, language n Defines software qualities

Topic 3Summer Why Spend a Lot of Time? n A requirements specification is the source for all future steps in the software life cycle –Lays the basis for a mutual understanding Consumer (what they get) Software producer (what they build) –Identifies fundamental assumptions –Potential basis for future contracts n Better get it right –Upon delivery, some software is actually rejected by customers n Changes are cheap –Better make them now rather than later

Topic 3Summer Characteristics of a Requirements Specification (the Document) n Unambiguous –Requires precise, well-defined notations/language n Complete: any system that satisfies it is acceptable n Verifiable (testable) n No implementation bias (external properties only) –"One model, many realizations"

Topic 3Summer Software Qualities n Correctness n Reliability n Robustness n Performance n User friendliness n Verifiability n Maintainability n Repairability n Safety n Evolvability n Reusability n Portability n Understandability n Interoperability n Productivity n Size n Timeliness n Visibility These qualities often conflict with each other

Topic 3Summer Your Tasks 1. Read and study slides of this lecture