| Date post: | 31-Dec-2015 |
| Category: |
Documents |
| Upload: | nora-oconnor |
| View: | 223 times |
| Download: | 3 times |
1
CSE
2102
CSE
2102
Chapter 3: SWE PrinciplesChapter 3: SWE Principles
Prof. Steven A. DemurjianComputer Science & Engineering Department
The University of Connecticut371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]://www.engr.uconn.edu/
~steve(860) 486 – 4818
(860) 486 – 3719 (office)
2
CSE
2102
CSE
2102
What is a Software Engineering Principle? A Software Principle is a fundamental value that
guides a process Goals of accounting principles:
Timely financial reports Comparable financial reports Specific Totals Equivalent (checkbook balances)
What are Goals of Software Engineering Principles? Serve as Rules of the Software Game Characterizes Good Practice in Process Achieved at Various Stages of the Process form
Requirements Specification to Deployment
3
CSE
2102
CSE
2102
Software Engineering Principles Principles involve software engineering process and
its product Methods and techniques: systematic approaches
for modeling software. Principles become practice through methods and
techniques Methodology: organizing methods/techniques into
a process that assists in problem solving. Methodology can be enforced
Seven important principles that may be used in all phases of software development
Modularity is the cornerstone principle supporting software design
4
CSE
2102
CSE
2102
Software Engineering Principles Principles Apply to Software Process and its Product
Methods: Systematic Approach to Model Software Methodology: Organizing Methods/Techniques
into a Process that Assists in Problem Solving Methodologies can be Enforced by Tools
Software Engineering Principles Rigor and Formality Separation of Concerns Modularity Abstraction Anticipation of Change Generality Incrementality
Reflection – What Does OO Provide/Inhibit?
5
CSE
2102
CSE
2102
What are Software Principles? 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
SoftwarePrinciples
Methods &Techniques
Methodologies
Tools
6
CSE
2102
CSE
2102
Why are Software Principles Needed? Characteristics of Target Software
Users are Non-Computing Personnel Problems are Large and Must be Decomposed Programming-in-the-Large for Teams Reliability and Evolvability Requirements Designing/Developing for Today and Future Program and Product Families Leverage Language Capabilities for Enforcement
Morals Applications Development has Evolved to Teams Successful Products Cross Hardware/OS
Boundaries Must Bring Stability and Oversight to Process
7
CSE
2102
CSE
2102
Rigor and Formality: Motivation Problem statement:
Write program that computes square root of a number What is wrong/missing in this simple problem
statement? What is the range of numbers that will be accepted
as input? What is the output of the program if the input
number is positive? Positive square root, negative square root, or both.
What is the output of the program if the input number is negative? Error message, complex root, or both?
8
CSE
2102
CSE
2102
Rigor and Formality: Motivation More rigorous problem statement:
Write a program to compute the square root of a given number. The program accepts positive and negative numbers as well as zero as input. If the input is a positive number, then the output should be both positive and negative square roots of the number. If the input is zero, then the output should be zero. If the input is a negative number, then the program should print an error. Tries to consider and anticipate all the situations Tries to define or specify precisely the behavior for
all the situations Can you find anything lacking in this problem
statement?
9
CSE
2102
CSE
2102
Rigor and formality: MotivationRigor and formality: Motivation
Formality is rigor at the highest degreeUse of mathematical equations
to specify the behavior
SquareRoot(x)Input x;Output = + sqrt(x), if x > 0 = 0 if x = 0 = “Error” if x < 0
10
CSE
2102
CSE
2102
Rigor and Formality Software Design/Development Creative Process Creativity Leads to Imprecision/Inaccuracy Rigor Needed for Thoroughness
Understand and Define Problem Reliable, Cost Efficient, and Robust
Formality: Highest Degree of Rigor Where is the Guarantee in Software? Definition: Is Specification Complete? Implementation
Does Software Match Requirements? Is Software Error-Free?
Building Bridges vs. Building Software
11
CSE
2102
CSE
2102
Rigor and Formality 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 Specification vs. Design vs. Implementation Maintenance vs. Evolution
Rigor and Formality re. Software Qualities Reusability: Formal Components, e.g.,Generics Portability: Easing the Transition Understandability: Expected Behavior Interoperability: Interactions Among Components
and Systems
12
CSE
2102
CSE
2102
Separation of Concerns Identify the Different Aspects of Problem
Time Considerations - Scheduling Focus on Qualities of Primary Concern
Address Qualities Separately for Each Problem Performance vs. Correctness vs. Interoperability
Alternate Views of Problem - Data vs. Control Size-Oriented Decomposition
Today’s Applications involve Interoperability of New C/S, Legacy, COTS, Databases, etc. Multiple Prog. Languages (C, C++, Java, etc.) Heterogeneous Hardware/OS Platforms
Separation of Concerns is Critical!
13
CSE
2102
CSE
2102
Separation of Concerns Divide and Conquer Problem Solving Technique
Binary Search as Sample 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
Separate Concerns Compartmentalize Towards Components
Software Applications Continue to Keep Up with Hardware Improvements Faster CPUs, More Memory/Disk Still Exceeding Workstation “Capabilities”
14
CSE
2102
CSE
2102
Separation of Concerns Determine and Assess Different concerns:
Functional correctness for positive inputs Robustness for negative inputs Performance
Address different concerns separately: First provide an implementation which is
functionally correct. Exception handling to handle negative inputs. Replace the simple implementation by an efficient
one to improve performance.
15
CSE
2102
CSE
2102
Separation of Concerns Why is Separation of Concerns Useful?
Interaction Techniques (RPC, CORBA, Java RMI, .NET, etc.) have Substantially Improved
Applications Contain Many Commonalities that are Separate Concerns: GUI, DB, Communications
Reduction in Problem Complexity Leads to Solutions that are Easier to Understand and Explain Conceptualize and Work with
High-Level Decisions Can Quickly Yield Component Based Solution
Strongly Promotes Team-Oriented Development What is Each Person Responsible for? How do the Different Components Interact?
16
CSE
2102
CSE
2102
Process of Separation of Concerns Go through software design and development phases
one after the other (as in waterfall) Separation of concerns by separating activities
with respect to time Keep product requirements separate
Functionality Performance User interface and usability
17
CSE
2102
CSE
2102
Separation of Concerns – High Level Ex. How is an E-Commerce Application Quantified?
Graphical User Interface (html vs. Java Struts) Server Component (SOAP or JSON services) Database Component
Use Hibernate to Hide Platform (MySQL, SQL Server) Security Component
Encryption used on Database https for Secure Exchange for Payment
Logical Separation of Components
18
CSE
2102
CSE
2102
Low Level Example Problem statement:
Write a program to compute the square root of a given number. The program accepts positive and negative numbers as well as zero as input.
If the input is a positive number, then the output should be both positive and negative square roots of the number.
If the input is zero, then the output should be zero. If the input is negative, the Program should print
an error message. The output should be produced in 2 ms.
19
CSE
2102
CSE
2102
Modularity: Motivation Modularity: Motivation
Problem statement:Write a program to compute the square root
of a given number. The program accepts positive and negative numbers as well as zero as input. The
program accepts input from an ASCII file. If the input is a positive number, then the
output should be both positive and negative square roots of the number. If the input is zero,
then the output should be zero. The output should be written to a file.
Should the code for input and output be embedded with the code that computes square root,
or should the code be in separate modules?
20
CSE
2102
CSE
2102
What are Modules? A Complex System may Be Divided into Simpler
Pieces Called Modules A Module
Describes Both State and Behavior Module Employee Includes Instance Variables,
Operations, and Program Variables Single Instance Shared by All Users
A System Composed of Modules is Called Modular Supports Application of Separation of Concerns
When Dealing with a Module we Can Ignore Details of Other Modules
Modularity Supports Information Hiding Import from Other Modules Export to Other Modules
21
CSE
2102
CSE
2102
Modularity Compose and Design Systems as Set of Modules Two-Phase Application of Separation of Concerns
Phase I: Module Level Define Details of Individual Modules What Well-Defined Tasks Does Module Perform?
Phase II: System Level Characterize Interactions Among All Modules What Does a Module Needs from Other Modules?
Methodological Approaches Top-Down: Phase II Followed by Phase I Bottom-Up: Phase I Followed by Phase II
Modularity Inherent in Engineering Disciplines Modularity Transcends Computing Areas
22
CSE
2102
CSE
2102
Modularity Benefits of Modularity
Decomposability: Problem to subproblems Composability: Combine subproblems to solution Understanding: Capability of understanding a system by
understanding its pieces Modifiability: Capability of modifying a system by
modifying its pieces Example: Car as Component vs. 1 Cubic Ft. Units Key Supporting Concepts
Cohesion Degree to Which Parts of a Module are Related Engine, Individual Engine Components, etc.
Coupling Amount of Interdependence Between Modules Is Engine Coupled to Floor Mats?
What Does “Good” Modularization Require?
23
CSE
2102
CSE
2102
Cohesion and Coupling Each Module Should Be Highly Cohesive
Module Understandable as a Meaningful Unit Components of A Module are Closely Related yo
One Another Modules Should Exhibit Low Coupling
Modules Have Low Interactions With Others Understandable Separately
What do Each Represent Below?
24
CSE
2102
CSE
2102
Modularity Modularity Supported in Programming Languages C
“.h/.c” Pairs Subdirectories at OS Level or Compiler Makes Ad-hoc Modularity
C++ “.h/.c” Pairs for Classes Adds Abstraction, Public Interface, Private
Implementation Subdirectories at OS Level or Compiler Makes
Ada95/Java Adds the Package Concept Rules for Interactions/Visibility Within/Among
Packages
25
CSE
2102
CSE
2102
Abstraction: MotivationAbstraction: Motivation
For a module, which uses the square root program, the only relevant
information is the input it accepts and the output it provides.
It need not be concerned with how the square root computation is
implemented.Thus, the user of the square root program is only concerned with its
input/output behavior and may ignore the details of the implementation.
26
CSE
2102
CSE
2102
Abstraction Remove/Hide Unimportant Details to Allow more
Important Aspects of a Product to be Considered Widely Utilized to Reduce Complexity Abstractions Dominate Computing
Paradigms (OO, Top-Down, Functional, etc.) Design Models (ER, UML, etc.) Programming Languages (C, C++, Java, etc.)
People Think and Learn in Abstractions Goals of Advances in Design and Programming
Provide Robust Sets of Abstractions Allow Modeling to Occur Close to Real World
27
CSE
2102
CSE
2102
Abstraction Abstraction yields models
For example, when requirements are analyzed we produce a model of proposed application.
Model can be a formal or semiformal description Possible to reason about the system by reasoning about
the model Programming language semantics via abstract machine
that ignores details of real machines used for implementation Abstraction ignores details such as precision of
number representation or addressing mechanisms Abstractions in process
When we do cost estimation we only take some key factors into account
We apply similarity with previous systems, ignoring detail differences
28
CSE
2102
CSE
2102
Sample Abstractions
Rodents
Rats Raccoons Squirrels
Pointing Device
Touch Pad Mouse Light Pen
Track Ball Non-Track Ball
Compiler Representations ASCII File - Source
Parse Tree Symbol Table
Data Flow Graph Control Flow Graph
Assembly Code Executable Code
Some Abstractions Classify the “World” Rodents and Pointing Device General (Pointing Device) to
Specific (Track Ball) Inheritance Hierachies
Other Abstractions Capture Different States of Information Structured ASCII Source Complex Data Structures Executable Instructions
29
CSE
2102
CSE
2102
Other Abstraction Examples Example 1:
User Interface of Watch (Buttons) Abstracts from Watch's Internals for Purpose of Setting Time
Other Abstractions Needed to Support Repair Example 2:
Equations Describing Complex Circuit (Amplifier) Allows Designer to Reason About Signal Amplification
Equations May Approximate Description, Ignoring Details that Yield Negligible Effects (e.g., Connectors Assumed to be Ideal)
30
CSE
2102
CSE
2102
Abstraction in Programming Languages Abstract Data Types/Classes Well Established in OO Older Language Like C can Mimic ADTs/OO
Define struct (in .h file) and code (in .c file) Organization Mimics OO Issue: No Enforcement at Compiler
New Languages (Ada, Java, C++) Enforce Abstraction Class with Attributes/Methods Public, Protected, and Private Portions Interfaces customizable for Application Generics Compiler Enforces Abstraction Principles
31
CSE
2102
CSE
2102
Anticipation of Change: MotivationAnticipation of Change: Motivation
Problem Statement:Consider the square root program. In addition to
accepting input and writing output to a file, the program should also accept input from a terminal and provide output to a terminal.
File i/p Square root File o/p
Terminal i/p Terminal o/p
What if a combination of file and terminal I/p and o/p is desired?
32
CSE
2102
CSE
2102
Anticipation of Change 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
Basis of Evolvability and Reusability Requires Automated Support (SCCS, etc.) for
Configuration and Version Management Impacts Software Production Process
Can Future Products be Predicted? Is Planning Cycle 5 or More Years? What is Planning Cycle for Mobile Apps?
33
CSE
2102
CSE
2102
Generality: MotivationGenerality: Motivation
Square root routine is being written for use in an application where itsinput will never be negative.
- A quick solution will be write a program that does not handle
negative numbers at all. Later, a new application needs
square root computation. But this, time, the output should be a
complex root, if input is negative. - If the original program considered
the case of general numbers, it could be reused in the new application.
34
CSE
2102
CSE
2102
Generality For a Given Problem, Look for a General Problem and
Solve Supermarket System vs. Inventory Control Hospital Application vs. Health Care Product
Adapt General Solution to Specific Problem Inventory Control for Supermarket, Auto Parts,
Video Tape Rental, etc. 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, … Generality vs. Performance vs. Cost
35
CSE
2102
CSE
2102
GeneralityGenerality
Three Classes of Softwarein a Typical Software Application
Domain-Independent20% Domain-Specific
65%
Application-Specific15%
36
CSE
2102
CSE
2102
High-Tech Supermarket System (HTSS) Automate the Functions and Actions
Cashiers and Inventory Updates User Friendly Grocery Item Locator Fast-Track Deli Orderer Inventory Control
User System Interfaces Cash Register/UPC Scanner GUI for Inventory Control Shopper Interfaces Locator and Orderer Deli Interface for Deli Workers
We’ll Introduce and Utilize Throughout Course Example from 1990s that is Now in Practice
37
CSE
2102
CSE
2102
The HTSS Software ArchitectureThe HTSS Software Architecture
ICICICIC
CRCRCRCR
CRCR
CRCR
ILILILIL
ILIL
SDOSDO
SDOSDO EDOEDO
EDOEDO
OrderOrder
PaymentPayment
ItemItemItemDBItemDBLocalLocal
ServerServer
Non-LocalClient Int.
InventoryInventoryControlControl
ItemDBItemDBGlobalGlobalServerServer
OrderDBOrderDB
SupplierDBSupplierDB
CreditCardDBCreditCardDB
ATM-BanKDBATM-BanKDB
IL: Item LocatorIL: Item LocatorCR: Cash RegisterCR: Cash RegisterIC: Invent. ControlIC: Invent. ControlDO: Deli Orderer forDO: Deli Orderer for Shopper/EmployeeShopper/Employee
38
CSE
2102
CSE
2102
Reusability in HTSS Domain
Where do Changes for Other Domains Occur?
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)
Root classes for Items, ItemDB, etc., which are Most General.
Inventory Control/Other Components.
Classes Specific to Grocery Store Domain.
39
CSE
2102
CSE
2102
Reusability in HTSS Domain
Specific Applications for Big Y or Shaw’s or Stop/Shop (S)
Root classes for Items, ItemDB, etc., which are Most General.
Inventory ControlOther Components.
Classes Specific to Grocery Store Domain.
Inventory Control Tool for Ordering
Items from Suppliers
Cost Accounting Tool for Tracking
Net and Gross Profit
40
CSE
2102
CSE
2102
Incrementality Accepted Practice Across Disciplines
Construction of Houses and Major Projects Baking via Recipes Win 3.1, Win 95, 98, NT, 2K, XP, Media, 7, 8 etc.
An Engineering Approach to Problem Solving Difficult to Anticipate What to Build
Would you have Guessed the Role of Mobile Computing 5 year Ago?
1st iPad in April 2010 Can’t be Ignored for “Future Products” Future Tools Browser Look-and-Feel
Accepted Practice in Computing Alpha and Beta Versions Adding Features and Tuning for Performance
41
CSE
2102
CSE
2102
Incrementality Products are Built in Increments
Quicker to Market Focused, Less Errors in Smaller Increments Phased Prototypes with Increasing Functions
Difficulty in Constructing Solutions to Complex Computing Problems Utilize Rapid Prototyping to Discern Requirements
from Users Allow Designers/Developers to Learn Domain
Incrementality Ideal Companion to OO Paradigm Add Classes for Successive Prototypes Include New Functionality in Existing Classes
42
CSE
2102
CSE
2102
Incrementality Examples iPhone History:
1st in Jan 07
Android History: 1st in Nov 07; more robust versions in Apr 09 18 API Levels with Release of Jelly Bean (July 24) 900 million devices, 9 OS versions
43
CSE
2102
CSE
2102
Case Study: Compiler Compiler Construction is an Area in CSE with
Systematic Formal Design Methods RE for Formal Descriptions of Lexical Tokens BNF For Formal Description of Language Syntax
Separation of Concerns: When Designing Optimal Register Allocation
Algorithms (Runtime Efficiency) Don’t Worry about Runtime Diagnostic Messages (User Friendliness)
Modularity: Compilation Process Decomposed Phases Lexical Analysis Syntax Analysis (Parsing) Code Generation Phases Can Be Associated With Modules
44
CSE
2102
CSE
2102
Representation of Modular Structure Boxes Represent Modules Directed Lines Represent Interfaces
Lexicalanalysis
Parsetree
Sourcecode
Symboltable
Objectcode
“Tokenized”code
Parsing Codegeneration
Lexicaldiagnostics
Syntax diagnostics
45
CSE
2102
CSE
2102
Module Decomposition may be Iterated Further Modularization of Code-Generation Module
46
CSE
2102
CSE
2102
Other Software Principles Abstraction:
Intermediate Machine Code (Java Bytecode) for Code Portability
Anticipation of Change: Source Language (Due to Standards Committees) Target Processor (or OS) I/O Devices
Generality Intermediate Code Bridges uo Multiple Targets Compiler Compilers (Lex/Yacc And Variants)
Incrementality Deliver Version For A Subset Of The Source
Language Deliver Compiler With Little Or No Optimizations
47
CSE
2102
CSE
2102
Modularity and Abstraction in JavaModularity and Abstraction in Java
48
CSE
2102
CSE
2102
Java Virtual Machine (JVM)
JVM is a Platform Specific Program which Interprets and Executes Java Code
JVM Interprets and Executes Bytecodes
JVM Targeted as Small/Efficient - Embeddable within Consumer Electronics
JVM Stack Based Machine - Simulates Real Processor
CA FE BA BE 00 03 00 2D 00 3ECA FE BA BE 00 03 00 2D 00 3E08 00 3B 08 00 01 08 00 20 0808 00 3B 08 00 01 08 00 20 08
49
CSE
2102
CSE
2102
Packages in Java Allows Related Classes to be Grouped into a Larger
Abstraction Similar to Ada95 Packages Unavailable in C++
Utilization of Packages for SW Design and Development Components, Modularization, Groupings Enforcement by Compiler of Package Rules
Overall, Packages Enhance the Control and Visibility to Fine-Tune Who Can See What When
50
CSE
2102
CSE
2102
The Java API Packages Application Programming Interface (API) Java Defined - Building Blocks/Libraries Java Platform 1.2/2 Core API
java.applet java.rmi java.awt java.rmi.dgc java.awt.datatransfer java.rmi.registry java.awt.event java.rmi.server java.awt.image java.security java.beans java.security.acl java.io java.security.interfaces java.lang java.sql java.lang.reflect java.text java.math java.util java.net java.util.zip
Power of Java Contained within APIs
51
CSE
2102
CSE
2102
Abstraction/Generality in Java
java.lang.Object
java.awt.Component
java.awt.Container
java.applet.Applet
your applet
Everything in Java inherits from the
Object classEvent-handling
and drawing capabilities
Ability to hold components
Limits what an Applet can
and cannot do
Every Applet is a subclass of the Applet class.
52
CSE
2102
CSE
2102
Principles and OO Paradigm Rigor and Formality
Difficult to Identify Strong Link Separation of Concerns
Define Classes at Different Abstraction Levels Modularity
Classes are Components of Solution Abstraction
Public Interface and Private Implementation Anticipation of Change
Design Classes for Change Generality
Generics and Solving General Problems Incrementality
New and Expanded Classes over Time
53
CSE
2102
CSE
2102
Software Principles in 3 Tier SettingSoftware Principles in 3 Tier Setting
Which Principles are Most Important and Why?Rigor and Formality, Separation of Concerns
Modularity, Abstraction, Anticipation of ChangeGenerality, Incrementality
54
CSE
2102
CSE
2102
Software Principles in 4 Tier SettingSoftware Principles in 4 Tier Setting
Which Principles are Most Important and Why?Rigor and Formality, Separation of Concerns
Modularity, Abstraction, Anticipation of ChangeGenerality, Incrementality
55
CSE
2102
CSE
2102
Recall: What does OO Offer? Classes are a Very Good Technique to Modularize the
Components of the System Abstraction
Classes and Objects Usually Represent Concepts from the Real World, Abstracting Unnecessary Details.
Encapsulation Classes Encapsulate their Behavior into Manageable
Units, by Hiding their Implementation to the Clients Classification
Hierarchies Provide a Good way to Organize and Classify Classes
56
CSE
2102
CSE
2102
Classic OO program Survey Management example
Concerns are Separated into Different Classes
class Survey_List { public void Add_Survey_Header(Survey_Header sh) { } public List Survey_Title_Search(String title) { } public void Update_Survey_List() { } public void Delete_Survey_Header(Survey_Header sh) { }}
class Survey_List { public void Add_Survey_Header(Survey_Header sh) { } public List Survey_Title_Search(String title) { } public void Update_Survey_List() { } public void Delete_Survey_Header(Survey_Header sh) { }}
class Survey_Header { public void Create_Survey_Header() { } public void Add_Question(String q) { } public void Add_Special_Question(String sq) { }}
class Survey_Header { public void Create_Survey_Header() { } public void Add_Question(String q) { } public void Add_Special_Question(String sq) { }}
class Public_Survey_Results { public List Get_General_Statistics() { } public List Get_Questions() { }}
class Public_Survey_Results { public List Get_General_Statistics() { } public List Get_Questions() { }}
57
CSE
2102
CSE
2102
When and How does OO fail? The Object-Oriented Paradigm Provides the Class as
the Main unit to Decompose a Software System A Good Designer can Decompose the Main Concerns
of an Application into Classes and Hierarchies However, no Matter how Good is the Design there are
still Concerns that Cannot be Well Modularized Sound Modeling for One Concern (GUI) may Lead
to Poor Modeling for Another Concern (Database) This Leads to:
Scattering – Code for Concern is Distributed Tangling – Code for Multiple Concerns is Present in
Each Abstraction (Class, Method, etc.)
58
CSE
2102
CSE
2102
Survey Management Application A Visual Example
Access-control Code is Scattered Through Both Classes
Each Class has Tangled both Access-control Code and Domain-specific Code
public void Survey_Title_Search(String title) { if (user.canSearch()){ slist.search(title); ...}
public void Survey_Title_Search(String title) { if (user.canSearch()){ slist.search(title); ...}
public void public void Add_Special_Question(String sq) { if (user.canAddSpecialQuestion()){ Question_List.add(sq); ...}
public void public void Add_Special_Question(String sq) { if (user.canAddSpecialQuestion()){ Question_List.add(sq); ...}
59
CSE
2102
CSE
2102
What Occurs at Larger Scale?
Consider Apache Tomcat as a Set of Abstractions that Represents its Broad Functionality for: XML Parsing UML Pattern Matching Logging of User Activity Many Other Capabilities
Represented Pictorially as:
60
CSE
2102
CSE
2102
An Example of Good Modularity XML Parsing in org.apache.tomcat
Red shows Relevant lines of code Nicely Located in one box – Well Defined
© Copyright 1998-2002 Palo Alto Research Center Incorporated. All rights reserved. ApsectJ.org.
61
CSE
2102
CSE
2102
Another Example of Good Modularity URL Pattern Matching in org.apache.tomcat
Red shows Relevant lines of code Nicely Located in two boxes – (using inheritance)
© Copyright 1998-2002 Palo Alto Research Center Incorporated. All rights reserved. ApsectJ.org.
62
CSE
2102
CSE
2102
An Example of Poor Modularity Logging in org.apache.tomcat
Red Shows lines of code Handle Logging Not in just one place Not even in a small number of places Just a Mess…
© Copyright 1998-2002 Palo Alto Research Center Incorporated. All rights reserved. ApsectJ.org.
63
CSE
2102
CSE
2102
Moral of Story For Improved SWD&D, can Separation of All
Important Concerns of an Application be Promoted? Design and Implementation Languages Should
Provide Decomposition Mechanisms Understand the
Requirements By Partitioning Problem into Pieces Composition Mechanisms Provide Infrastructure to
Assemble Pieces of System into a Whole More Powerful Decomposition Mechanisms
Needed on Top of OOP! Aspect-Oriented Software Development one Solution
64
CSE
2102
CSE
2102
Chapter 3 - SummaryChapter 3 - Summary Software Principles are Precepts Under While We
Strive for Well-Design, Well-Formulated Software Three Natural Groupings
Rigor and Formality Provable Capabilities of Software Critical for Compilers (Bytecode Verifier) and other
Applications (Embedded, Real-Time, etc.) Separation of Concerns, Modularity, Abstraction
Conceptualization of Problem Stepping Back and Thinking
Anticipation of Change, Generality, Incrementality If you Build it, it will Change Design for Change from Day 1
