CSE 230 Chapter 3 SWE Principles Prof Steven

CSE 230 Chapter 3: SWE Principles Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269 -2155 steve@engr. uconn. edu http: //www. engr. uconn. edu/~stev e (860) 486 – 4818 (860) 486 – 3719 (office) CH 3. 1

Software Engineering Principles m CSE 230 m Principles Apply to Software Process and its Product q Methods and Techniques: Systematic Approaches for Modeling Software q Methodology: Organizing Methods/Techniques into a Process that Assists in Problem Solving q Methodologies can be Enforced by Tools Software Engineering Principles q Rigor and Formality q Separation of Concerns q Modularity q Abstraction q Anticipation of Change q Generality q Incrementality CH 3. 2

What are Software Principles? m CSE 230 m Software Principles are the Guiding Factors that Govern any and all Software Design/Development Software Principles Transcend the Application to Focus on Software Engineering Process/Product Tools Methodologies Methods & Techniques Software Principles CH 3. 3

Why are Software Principles Needed? m CSE 230 m Characteristics of Target Software q Users are Non-Computing Personnel q Problems are Large and Must be Decomposed q Programming-in-the-Large for Teams q Reliability and Evolvability Requirements q Designing/Developing for Today and Future q Program and Product Families Morals q Applications Development has Evolved to Teams q Successful Products Cross Hardware/OS Boundaries q Must Bring Stability and Oversight to Process CH 3. 4

CSE 230 Rigor and Formality m m Software Design/Development Creative Process Creativity Leads to Imprecision/Inaccuracy Rigor Needed for Thoroughness q Understand Define Problem q Reliable, Cost Efficient, and Robust Formality: Highest Degree of Rigor q Where is the Guarantee in Software? q Definition: Is Specification Complete? q Implementation Ø Does Software Match Requirements? Ø Is Software Error-Free? q Building Bridges vs. Building Software CH 3. 5

Rigor and Formality m CSE 230 m m m Software Engineers Active Partners in Rigor and Formality Requirements Rigor and Formality Strongly Influence Reliability and Verifiability! Rigor and Formality Impact Across Multiple Phases of Software Design Process q Specification vs. Design vs. Implementation q Maintenance vs. Evolution Rigor and Formality re. Software Qualities q Reusability: Formal Components, e. g. , Generics q Portability: Easing the Transition q Understandability: Expected Behavior q Interoperability: Interactions Among Components and Systems CH 3. 6

Separation of Concerns m CSE 230 Divide and Conquer Problem Solving Technique q Binary Search as Sample q Tracking Dependencies Among Sub-Problems Ø Which Sub-Problems are (In)Dependent? Ø Can Problem Viewed from Differing Perspectives? Promoting Parallelization and Separation As Application Complexity Increases q Separate Concerns q Compartmentalize Towards Components Software Applications Continue to Keep Up with Hardware Improvements q Faster CPUs, More Memory/Disk q Still Exceeding Workstation “Capabilities” q m m CH 3. 7

Separation of Concerns m CSE 230 Identify the Different Aspects of Problem q Time Considerations - Scheduling q Focus on Qualities of Primary Concern Ø Address Qualities Separately for Each Problem Ø Performance vs. Correctness vs. Interoperability Alternate Views of Problem - Data vs. Control q Size-Oriented Decomposition Today’s Applications involve Interoperability of q New C/S, Legacy, COTS, Databases, etc. q Multiple Prog. Languages (C, C++, Java, etc. ) q Heterogeneous Hardware/OS Platforms Separation of Concerns is Critical! We’ll Explore Aspect-Oriented Programming that Focuses on Separation of Concerns q m m m CH 3. 8

Separation of Concerns m CSE 230 Why is Separation of Concerns Useful? q Interaction Techniques (RPC, CORBA, Java RMI, . NET, etc. ) have Substantially Improved q Applications Contain Many Commonalities that are Separate Concerns: GUI, DB, Communications q Reduction in Problem Complexity Leads to Solutions that are Easier to Ø Understand Explain Ø Conceptualize and Work with m m High-Level Decisions Can Quickly Yield Component Based Solution Strongly Promotes Team-Oriented Development q What is Each Person Responsible for? q How do the Different Components Interact? CH 3. 9

What are Modules? m CSE 230 m m m A Complex System may Be Divided into Simpler Pieces Called Modules A Module q Describes Both State and Behavior q Module Employee Includes Instance Variables, Operations, and Program Variables q Single Instance Shared by All Users A System Composed of Modules is Called Modular Supports Application of Separation of Concerns q When Dealing with a Module we Can Ignore Details of Other Modules q Modularity Supports Information Hiding Ø Import from Other Modules Ø Export to Other Modules CH 3. 10

CSE 230 Modularity m m Compose and Design Systems as Set of Modules Two-Phase Application of Separation of Concerns q Phase I: Module Level Ø Define Details of Individual Modules Ø What Well-Defined Tasks Does Module Perform? q Phase II: System Level Ø Characterize Interactions Among All Modules Ø What Does a Module Needs from Other Modules? m m m Methodological Approaches q Top-Down: Phase II Followed by Phase I q Bottom-Up: Phase I Followed by Phase II Modularity Inherent in Engineering Disciplines Modularity Transcends Computing Areas CH 3. 11

Modularity m CSE 230 m m Three Goals of Modularity q Decomposability: Problem to Subproblems q Composability: Combine to Solution q Abstraction: Capability of Understanding Example: Car as Component vs. 1 Cubic Ft. Units Key Supporting Concepts q Cohesion Ø Degree to Which Parts of a Module are Related Ø Engine, Individual Engine Components, etc. q Coupling Ø Amount of Interdependence Between Modules Ø Is Engine Coupled to Floor Mats? m What Does “Good” Modularization Require? CH 3. 12

Cohesion and Coupling m CSE 230 m m Each Module Should Be Highly Cohesive q Module Understandable as a Meaningful Unit q Components of A Module are Closely Related yo One Another Modules Should Exhibit Low Coupling q Modules Have Low Interactions With Others q Understandable Separately What do Each Represent Below? CH 3. 13

CSE 230 Modularity m m Modularity Supported in Programming Languages C q “. h/. c” Pairs q Subdirectories at OS Level or Compiler Makes q Ad-hoc Modularity C++ q “. h/. c” Pairs for Classes q Adds Abstraction, Public Interface, Private Implementation q Subdirectories at OS Level or Compiler Makes Ada 95/Java q Adds the Package Concept q Rules for Interactions/Visibility Within/Among Packages CH 3. 14

Abstraction m CSE 230 m m Remove/Hide Unimportant Details to Allow more Important Aspects of a Product to be Considered Widely Utilized to Reduce Complexity Abstractions Dominate Computing q Paradigms (OO, Top-Down, Functional, etc. ) q Design Models (ER, UML, etc. ) q Programming Languages (C, C++, Java, etc. ) People Think and Learn in Abstractions Goals of Advances in Design and Programming q Provide Robust Sets of Abstractions q Allow Modeling to Occur Close to Real World CH 3. 15

Sample Abstractions CSE 230 Rodents Raccoons Pointing Device Squirrels Touch Pad Track Ball Compiler Representations ASCII File - Source Parse Tree Symbol Table Data Flow Graph Control Flow Graph Assembly Code Executable Code m m Mouse Light Pen Non-Track Ball Some Abstractions Classify the “World” q Rodents and Pointing Device q General (Pointing Device) to Specific (Track Ball) q Inheritance Hierachies Other Abstractions Capture Different States of Information q Structured ASCII Source q Complex Data Structures q Executable Instructions CH 3. 16

Other Abstraction Examples m CSE 230 m Example 1: q User Interface of Watch (Buttons) Abstracts from Watch's Internals for Purpose of Setting Time q Other Abstractions Needed to Support Repair Example 2: q Equations Describing Complex Circuit (Amplifier) Allows Designer to Reason About Signal Amplification q Equations May Approximate Description, Ignoring Details that Yield Negligible Effects (e. g. , Connectors Assumed to be Ideal) CH 3. 17

Anticipation of Change m CSE 230 m m m Software Changes and Evolves Throughout All Stages from Specification Onward Key is to Anticipate Future Changes Once Anticipated, Encapsulate Areas for Potential Changes into Targeted Portions of Product Is Anticipation of Change Unique to Computing? Handling Anticipation of Change q Basis of Evolvability and Reusability q Requires Automated Support (SCCS, etc. ) for Configuration and Version Management q Impacts Software Production Process Can Future Products be Predicted? Is Planning Cycle 5 or More Years? CH 3. 18

Generality m CSE 230 m m For a Given Problem, Look for a General Problem and Solve q Supermarket System vs. Inventory Control q Hospital Application vs. Health Care Product Adapt General Solution to Specific Problem q Inventory Control for Supermarket, Auto Parts, Video Tape Rental, etc. q Health Care Product for Hospital, MD Office, Dental Office, etc. Domain-and-Organization Specific Reuse What Products will Company Develop in Future? Leverage Additional Short-Term Effort with Long. Term Gains w. r. t. Maintenance, Reuse, … q Generality vs. Performance vs. Cost CH 3. 19

Generality CSE 230 CH 3. 20

CSE 230 High-Tech Supermarket System (HTSS) m m m Automate the Functions and Actions q Cashiers and Inventory Updates q User Friendly Grocery Item Locator q Fast-Track Deli Orderer q Inventory Control User System Interfaces q Cash Register/UPC Scanner q GUI for Inventory Control q Shopper Interfaces Locator and Orderer q Deli Interface for Deli Workers We’ll Introduce and Utilize Throughout Course CH 3. 21

The HTSS Software Architecture CSE 230 SDO IL IL IL EDO SDO EDO Payment CR CR IL: CR: IC: DO: Item Locator Cash Register Invent. Control Deli Orderer for Shopper/Employee Item IC Order IC Non-Local Client Int. Credit. Card. DB Inventory Control Item. DB Global Server Item. DB Local Server ATM-Ban. KDB Order. DB Supplier. DB CH 3. 22

Reusability in HTSS Domain CSE 230 Root classes for Items, Item. DB, etc. , which are Most General. Inventory Control/Other Components. Classes Specific to Grocery Store Domain. Specific Applications for Big Y or Shaw’s or Stop/Shop (S) m Where do Changes for Other Domains Occur? CH 3. 23

Reusability in HTSS Domain CSE 230 Root classes for Items, Item. DB, etc. , which are Most General. Inventory Control Tool for Ordering Items from Suppliers Inventory Control Other Components. Cost Accounting Tool for Tracking Net and Gross Profit Classes Specific to Grocery Store Domain. Specific Applications for Big Y or Shaw’s or Stop/Shop (S) CH 3. 24

Reusability in HTSS Domain CSE 230 Root classes for Items, Item. DB, etc. , which are Most General. Classes Specific to Grocery Store Domain. Inventory Control/Other Components. Classes for Large Supermarket Classes for Specialty Supermarket Classes for 24 Hour Convenience Specific Applications for Big Y or Shaw’s or Stop/Shop (S) CH 3. 25

Incrementality m CSE 230 m m m Accepted Practice Across Disciplines q Construction of Houses and Major Projects q Baking via Recipes q Win 3. 1, Win 95, 98, NT, 2 K, XP, Media, etc. An Engineering Approach to Problem Solving Difficult to Anticipate What to Build q Would you have Guessed the Role of Internet, Web, and Browsers 10 Years Ago? q Emerging Role of Cell-Cameras in Media q Can’t be Ignored for “Future Products” q Future Tools Browser Look-and-Feel Accepted Practice in Computing q Alpha and Beta Versions q Adding Features and Tuning for Performance CH 3. 26

Incrementality m CSE 230 m m Products are Built in Increments q Quicker to Market q Focused, Less Errors in Smaller Increments q Phased Prototypes with Increasing Functions Difficulty in Constructing Solutions to Complex Computing Problems q Utilize Rapid Prototyping to Discern Requirements from Users q Allow Designers/Developers to Learn Domain Incrementality Ideal Companion to OO Paradigm q Add Classes for Successive Prototypes q Include New Functionality in Existing Classes CH 3. 27

Case Study: Compiler m CSE 230 m m Compiler Construction is an Area in CSE with Systematic Formal Design Methods q RE for Formal Descriptions of Lexical Tokens q BNF Formal Description of Language Syntax Separation of Concerns: q When Designing Optimal Register Allocation Algorithms (Runtime Efficiency) Don’t Worry about Runtime Diagnostic Messages (User Friendliness) Modularity: Compilation Process Decomposed Phases q Lexical Analysis q Syntax Analysis (Parsing) q Code Generation q Phases Can Be Associated With Modules CH 3. 28

CSE 230 Representation of Modular Structure m m Boxes Represent Modules Directed Lines Represent Interfaces CH 3. 29

Module Decomposition may be Iterated m Further Modularization of Code-Generation Module CSE 230 CH 3. 30

Other Software Principles m CSE 230 m m m Abstraction: q Intermediate Machine Code (Java Bytecode) for Code Portability Anticipation of Change: q Source Language (Due to Standards Committees) q Target Processor (or OS) q I/O Devices Generality q Intermediate Code Bridges uo Multiple Targets q Compilers (Lex/Yacc And Variants) Incrementality q Deliver Version For A Subset Of The Source Language q Deliver Compiler With Little Or No Optimizations CH 3. 31

Modularity and Abstraction in Java CSE 230 CH 3. 32

Java Virtual Machine (JVM) m CSE 230 m JVM is a Platform Specific Program which Interprets and Executes Java Code JVM Interprets and Executes Bytecodes CA FE BA BE 00 03 00 2 D 00 3 E 08 00 3 B 08 00 01 08 00 20 08 m m JVM Targeted as Small/Efficient - Embeddable within Consumer Electronics JVM Stack Based Machine - Simulates Real Processor CH 3. 33

Packages in Java m CSE 230 m m Allows Related Classes to be Grouped into a Larger Abstraction q Similar to Ada 95 Packages q Unavailable in C++ Utilization of Packages for SW Design and Development q Components, Modularization, Groupings q Enforcement by Compiler of Package Rules Overall, Packages Enhance the Control and Visibility to Fine-Tune q Who Can See What When CH 3. 34

CSE 230 The Java API Packages m m m Application Programming Interface (API) Java Defined - Building Blocks/Libraries Java Platform 1. 2/2 Core API q q q m java. applet java. awt. datatransfer java. awt. event java. awt. image java. beans java. io java. lang. reflect java. math java. net java. rmi. dgc java. rmi. registry java. rmi. server java. security. acl java. security. interfaces java. sql java. text java. util. zip Power of Java Contained within APIs CH 3. 35

Abstraction/Generality in Java CSE 230 java. lang. Object Event-handling and drawing capabilities java. awt. Component java. awt. Container Limits what an Applet can and cannot do Everything in Java inherits from the Object class Ability to hold components java. applet. Applet your applet Every Applet is a subclass of the Applet class. CH 3. 36

Principles and OO Paradigm m CSE 230 m m m Rigor and Formality q Difficult to Identify Strong Link Separation of Concerns q Define Classes at Different Abstraction Levels Modularity q Classes are Components of Solution Abstraction q Public Interface and Private Implementation Anticipation of Change q Design Classes for Change Generality q Generics and Solving General Problems Incrementality q New and Expanded Classes over Time CH 3. 37

CSE 230 Software Principles in 3 Tier Setting Which Principles are Most Important and Why? Rigor and Formality, Separation of Concerns Modularity, Abstraction, Anticipation of Change Generality, Incrementality CH 3. 38

CSE 230 Software Principles in 4 Tier Setting Which Principles are Most Important and Why? Rigor and Formality, Separation of Concerns Modularity, Abstraction, Anticipation of Change Generality, Incrementality CH 3. 39

Chapter 3 - Summary m CSE 230 m Software Principles are Precepts Under While We Strive for Well-Design, Well-Formulated Software Three Natural Groupings q Rigor and Formality Ø Provable Capabilities of Software Ø Critical for Compilers (Bytecode Verifier) and other Applications (Embedded, Real-Time, etc. ) q Separation of Concerns, Modularity, Abstraction Ø Conceptualization of Problem Ø Stepping Back and Thinking q Anticipation of Change, Generality, Incrementality Ø If you Build it, it will Change Ø Design for Change from Day 1 CH 3. 40