Chapter 1: Preview of Software Engineering

1
Chapter 1 Preview of Software Engineering
Prof. Steven A. Demurjian Computer Science
Engineering Department The University of
Connecticut 371 Fairfield Road, Box
U-2155 Storrs, CT 06269-2155
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 4818 (860) 486 3719 (office)
2
Overview of Chapter 1

• Introduction to Software Engineering
• What is Software?
• What is Software Engineering?
• What Does Software Engineering Do?
• How is Software Engineered (Process)?
• Software Engineering vs. Computer Science?
• Designing/Building Systems for Today and Tomorrow
• Recall CSE133 and CSE134 Ideas
• Abstract Data Types (ADTs), Core and Advanced
  Object-Oriented Concepts, Benefits of OO
• Introduce Ideas of Component-Based Design
  Development
• Discuss Software Engineering for Distributed
  Application/System Development

3
What is Software?

• Software is the Definition and Organization of a
  Set of Tasks and Functionality Encapsulated into
  a Form that is Executable on a Computer
• What are Different Types of Software?
• Commercial-Off-the-Shelf (COTS)
• Government-Off-the-Shelf (GOTS)
• Legacy Written in an Old Programming Language
• Cobol, PL/1 (Y2k/SNET), Fortran, etc.
• C and C!
• Customized New Software
• Client vs. Server Software
• Database Management Systems/Applications

4
What is Software Engineering?

• Engineering The Application of Science to the
  Solution of Practical Problems
• Software Engineering The Application of CS to
  Building Practical Software Systems
• Programming
• Individual Writes Complete Program
• One Person, One Computer
• Well-Defined Problem
• Programming-in-the-Small
• Software Engineering
• Individuals Write Program Components
• Team Assembles Complete Program
• Programming-in-the-Large

5
What is Software Engineering?

• The Application Of Engineering To Software
• Field of CSE Dealing with Software Systems
• Large and Complex
• Built By Teams
• Exist In Many Versions
• Last Many Years
• Undergo Changes
• Definitions
• Application of a Systematic, Disciplined,
  Quantifiable Approach to the Development,
  Operation, and Maintenance of Software (IEEE
  1990)
• Multi-person Construction of Multi-version
  Software (Parnas 1978)

6
Why Software Engineering?

• Program Complexity Transcends Individual or Lone
  Programmer
• Software Engineering Targeted for
• Constructing Large Software Applications
• Defining Problem Clear and Completely
• Tools and Techniques to Support Process
• Team-Oriented Experience
• Software Engineering must Evolve to be an
  Engineering Discipline
• Software Engineering Must Promote and Support
  Multi-Person Construction of Multi-Version
  Software

7
Software Engineering - Historically

• Early Days
• 1950s Programmers Wrote Programs
• Early 1960s - Very Large Software Projects
  Constructed by Experts
• Mid-Late 1960s - Advent of Large Commercial
  Software Applications
• Large Systems Involved Teams of Individuals
• Coining the Term Software Engineering
• Towards a Software Engineering Discipline
• Individuals Couldnt see Big Picture
• Increase in Communication Time
• Personnel Changes Impact on Productivity
• SE Management, Organization, Tools, Theories,
  Methodologies, Techniques, etc.

8
Influences on Software Engineering

• Cost of Software Continues to Increase, Requiring
  More Efficient Software Production
• Software Acquisition vs. Outsourcing
• Software Reuse vs. Build-from-Scratch
• Complexity of Large Software Altered the View
  from Development PerspectiveConception Design
  DevelopmentIntegration Distribution
  DocumentationMaintenance Evolution Extension
• Software Engineering/Computer Science Growth
• 350,000 Information Technology Jobs Open
• 100,000 New Jobs per Year for 10 Years

9
Programmer vs. Software Engineer

• Individual with Good Skills
• Programming-in-the-Small
• Knowledge on
• Data Structures
• Algorithms
• Fluent in Several Programming Languages
• May Lack Formal Training
• Minimal Exposure to CS

• Part of a Team
• Programming-in-the-Large
• Design Approaches
• OO, Modules, etc.
• Top-Down/Bottm-Up
• Translates Requirements into Specifications
• Familiarity in Multiple Application Areas
• Converses with Users
• Sees Big Picture
• Can Model Application
• Good Communication and Interpersonal Skills

10
Waterfall Process Model
What is Major Disadvantage?
50
11
Software Lifecycle of Waterfall Model

• Requirements Analysis and Specification
• What is the Problem to Solve?
• What Does Customer Need/Want?
• Interactions Between SE and Customer
• Identify and Document System Requirements
• Generate User Manuals and Test Plans
• Design and Specification
• How is the Problem to be Solved?
• High-Level Design
• Determine Components/Modules
• Transition to Detailed Design
• Detail Functionality of Components/Modules

12
Software Lifecycle of Waterfall Model

• Coding and Module Testing
• Writing Code to Meet Component/Module Design
  Specifications
• Individual Test Modules in Isolation
• Drivers and Stubs to Simulate Behavior
• Integration and System Testing
• Integration of Components/Modules into Subsystems
• Integration of Subsystems into Final Program
• Delivery and Maintenance
• System Delivered to Customer/Market
• Bug Fixes and Version Releases Over Time

13
SWE vs. CSE Disciplines

• SWE to Programming Languages
• Modularity for Independent Compilation
• Separation of Design and Implementation
• Migrating Software Engineering Concepts into
  Programming Languages
• Classes in C (Implementation of ADTs)
• Packages in Java/Ada95 (Modularization)
• Programming Languages to SWE
• Precise Description of Requirements and Design
• Compiler Tools that Enhance D D
• Advanced Compilers and Libraries to Improve
  Productivity and Facilitate Reuse

14
SWE vs. CSE Disciplines

• SWE to Operating Systems
• Relationship Between Components and Versions
• Protected/Non-Protected Portions of OS
• Vehicle Through Which Programs Developed
• Operating Systems to SWE
• Virtual Machines - Evolving to Platform
  Independence with Java
• Levels of Abstraction Offered by OS
• Device Driver through GUI of OS
• Java Offers Strong OS Interactions
• Separation of Design and Implementation

15
SWE vs. CSE Disciplines

• SWE to Databases/Security
• Every Application Contains Database and Requires
  Access Control
• Storage of Large, Unstructured Objects
• Incorporation of Multi-Media and Web Based Data
• Versioning and Long-Term Transations
• Tracking Who Can Use/See What When
• Databases/Security to SWE
• Promoting Data Independence
• De-coupling Data Definition from Usage
• Databases as Expected Components in Applications
• Security in Applications and Across Networks

16
SWE vs. CSE Disciplines

• AI to SWE
• Exploratory Development and Scenarios
• Declarative Approach
• Natural Language and Voice Interfaces
• Theoretical Models to SWE
• Finite State Machines for Program Behavior
• Queueing and Simulation Models
• Petri Nets for Resource Behavior
• Regular and Context Free Grammars for Programming
  Languages/Compilers
• NP vs. P Computational Complexity

17
SWE Other Disciplines

• SWE and Management
• Management/Team Models Applied to Software
  Project Management/Process Control
• Important Test Domain to Test New Models and
  Theories for Management
• SWE and EE, ME, ChemE, CivilE, etc.
• Job Growth in Engineering Specific Software
• SWE and Biology, Chemistry, Medicine, etc.
• Medical Research and Informatics, Genome
• SWE and Financial Sector
• Banking, ATM Networks, Electronic Commerce, Funds
  Transfers, Program Trading, Stock and Brokerage
  Houses, etc.

18
Motivation and Background Concepts

• Information Engineering for 21st Century
• Creation of Information
• Generation of Information
• Utilization of Information
• Software, Database, Security, Performance
  Requirements for Application D D
• From Centralized to Distributed Solutions
• Tracing the History
• Abstract Data Types (ADTs) - 1970s
• Object-Oriented Paradigm - 1980s
• Component-Based D D 1990s
• Web-Based/Distributed Computing 2000s

19
Challenge for 21st Century

• Timely and Efficient Utilization of Information
• Significantly Impacts on Productivity
• Key to Many (All?) Companies Future
• Supports and Promotes Collaboration for
  Competitive Advantage
• Individual/Companies Use Information in New and
  Different Ways
• Collection, Synthesis, Analyses of Information
• Better Understanding of Processes, Sales,
  Productivity, etc.
• Dissemination of Only Relevant/Significant
  Information - Reduce Overload
• Fact We Live in an Increasingly Information
  Centered Society!

20
How is Information Engineered?

• Careful Thought to its Definition/Purpose
• Thorough Understanding of its Intended Usage and
  Potential Impact
• Insure and Maintain its Consistency
• Quality, Correctness, and Relevance
• Protect and Control its Availability
• Who can Access What Information in Which Location
  and at What Time?
• Long-Term Persistent Storage/Recoverability
• Cost, Reusability, Longitudinal, and Cumulative
  Experience
• Integration of Past, Present and Future
  Information via Intranet and Internet Access

21
Future Design Emphasis

• Focus on Information and its Behavior
• Answer the Following Questions
• What are Different Kinds of Information?
• How is Information Manipulated?
• Is Same Information Stored in Different Ways?
• What are Information Interdependencies?
• Will Information Persist? Long-Term DB? Versions
  of Information?
• What Past Info. is Needed from Legacy DBs or
  Applications?
• Who Needs Access to What Info. When?
• What Information is Available Across WWW?
• Is Processing Distributed? How are Distributed
  Artifacts Accessed? Replicated? Designed?

22
1970s - Abstract Data Types (ADTs)

• Proposed by B. Liskov (MIT) for CLU in 1975
• ADTs Promote Application Development From
  Perspective of Information and its Usage
• ADT Design Process
• Identify Kinds or Types of Information
• Encapsulate Information and Provide a Public
  Interface of Methods
• Hide Information and Method Code in the Private
  Implementation
• ADTs Correspond to User-Defined Data Types
• Analogous to Integer Data Type and , -, , etc.

23
Abstract Data Types (ADTs)

• Consider the following Example Stack ADT

24
ADT Design Guidelines

• Separation of Concerns and Modularity
• Problem Decomposable into Components
• Abstraction and Representation Independence
• Hiding Implementation of Components
• Changing without Impacting External View
• Incrementality and Anticipation of Change
• Components are Changed, Added, Refined, etc., as
  Needed to Support Evolving Requirements
• Cohesion Well-Defined Component Performs a
  Single Task or has a Single Objective
• Coupling Component Interactions are Known and
  Minimal

25
1980s - Object-Oriented Paradigm

• Object-Oriented Decomposition
• Decompose Problem into Agents which Perform
  Operations
• Emphasize Agents that Cause Actions
• Agents Comprised of Two Parts
• Hidden Implementation Data and Operations only
  Available to Agent
• Public Interface Operations Available to Clients
  of Agent
• An Agent Can Only be Modified by Operations
  Defined in either the Hidden Implementation or
  Public Interface

26
Core Object-Oriented Concepts

• Class
• The Type of an Agent
• Describes the Behavior
• Object
• The Instance of a Class
• Represents Actual Data Manipulated by Agents
• Maintains the State of Object
• Method
• Operation Defined on a Class
• Operates on ALL Instances of the Class
• Message
• Indicates that an Objects Method Invoked

27
An Example Employee Class
Class Employee
Main() //Declare Objects Employee
emp1(Steve,100.0) Employee emp2(Lois,
120.0) //Pass Messages //Invoke
Methods emp1.print_name() emp1.print_salary() em
p2.update_salary(10) emp2.print_name() emp2.prin
t_salary()
//Hidden Implementation Private //Instance Vars
char30 name float salary
//Public Interface Public void print_name()
void print_salary() void update_salary(float
i) Employee(char n, float s)
Whats Output of Main()?
Conclusion Each Object (emp1,emp2) has Own
Independent State that is Accessible via
Shared Public Interface of Class
Steve 100.0 Lois 130.0
28
Modules vs. ADTs/Classes

• Module
• Describes Both State and Behavior
• Module Employee Includes Instance Variables,
  Operations, and Program Variables
• Single Instance Shared by All Users
• Class
• Describes Only the Behavior
• Class Employee Omits Program Variables
• Multiple Independent Instances Share Same Class
  Declaration but have Separate States
• Key Difference Dynamic Nature of Classes Allows
  Instances to be Created as Needed

29
Advanced Object-Oriented Concepts

• Inheritance
• Controlled Sharing of Between ClassesGeneralizati
  on and Specialization
• Treat Instances of Different Classes in Uniform
  Fashion - Leading to
• Polymorphism/Dynamic Binding
• Run-Time Choice of the Method to be Invoked Based
  on the Type of the Calling Instance
• Message Passed is Type Dependent
• Generic A Type Parameterizable Class
• Stack has Parameter for Type of Element
• Creation of Program Variable Binds Stack Data and
  Methods to Specific Type of Element
• Stack(Real), Stack(Int), Stack(Employee)

30
A Quick Look at Inheritance
Supertype, Superclass, Parent Class, Base
Class Subtype, Subclass, Child Class, Derived
Class Descendants, Ancestors, Siblings
31
What Can Be a Class?
Private Data Public Interface Chunk
of Information Employee Name
Create_Employee() Class Address
Give_Raise(Amount) SSN
Change_Address(New_Addr) ...
...

• Represent Any Type of Historical or Long-Term
  Data that Exists in a Repository
• For Example, Supermarket Items, Automobile
  Registrations, IRS Returns, etc.

32
What Can Be a Class?
Private Data Public
Interface Functional Component ATM_Log
Acct_Name Check_Database(Name) Class
PIN_Number Verify_PIN(PIN) ...
Log_on_Actions(Name, PIN)
Reject() ...

• Represent a Functional Action that Performs a
  Well-Defined Task with Minimal Internal State
• For Example, Supermarket UPC Scan, Automobile
  Diagnostic Analyzer, etc.

33
What Can Be a Class?
Private Data Public Interface User
Interface ATM_User Action
Log_on_Steps() Class Balance
Acct_WithD(Amt) WD_Amt
Check_Balance(Number) ...
Deposit_Check() ... Or
--- Anything that you Want!

• Interaction Between User and System
• For Example, Supermarket Cashier, Browser
  Interface, etc.

34
Benefits of OO Paradigm

• Supports Reusable Software Components
• Creation and Testing in Isolation
• Integration of Working Components
• Designers/Developers View Problem at Higher Level
  of Abstraction
• Controls Information Consistency
• Public Interface Limits Access to Data
• Private Implementation Unavailable
• Promotes/Facilitates Software Evolution/Reuse
• Inheritance to Extend Design/Class Library
• Multiple Instances of Same Class

35
1990s Component Based D D

• ADTs as Unit of Abstraction/Conceptualization
• Classes are OO Equivalent of ADTs
• However, in Past 10 Years
• Computing Power has Exploded
• Application Complexity has Increased
• Classes are Part of Inheritance Hierarchy
• Inheritance Hierarchy Part of Application Class
  Library
• In Past 10 years
• Emergence of Java (and now .NET)
• Emergence of Java Beans
• Component-Based Development Tools

36
What are Components?

• How are Applications Conceptualized?
• Inheritance Hierarchies Partition Domain
• Packages as Collections or Related Classes
• Collections of Classes, Packages, Inheritance
  Hierarchies form Application Class Library
• How are Class Libraries Utilized?
• Use Individual Classes
• Use Package or Subset of Package
• Use Major Portions of Inheritance Hierarchies
• Tools Use at Most a Few Select Packages and/or
  Hierarchies
• Tools that Span Application Classes Represent
  Poorly Designed Software

37
Defining Component Concepts

• A Component is Composed of One or More Classes
  (or Other Components) and is Intended to Support
  a Constructed Unit of Functionality
• A Class Utilized in Multiple Components Maintains
  the Same Semantics in All of its Contexts
• What are Some Example Components?
• Graphical User Interface Widgets (see next slide)
• Major Reused Functionality
• Algorithm for Searching/Sorting
• Database Connection/Querying
• Application Specific
• Cost Accounting Component
• Computational Fluid Dynamics Component
• Note the Wide Range of Granularity Differences

38
What are Sample Components?

• Two Sample Components
• Date Component (Always Valid Date)
• Address Component (Consistency in Presentation)
• What is Attained?
• Consistent View
• Ability to Make Isolated Changes (4 to zip)
• Changes Seamlessly Included in Next Build

39
Components vs. Objects

• Components
• Business Oriented
• Coarser Grained
• Standards Based
• Multiple Interfaces
• Provide Services
• Fully Encapsulated
• Understood by Everyone

• Objects
• Technology-Oriented
• Fine Grained
• Language Based
• Single Interface
• Provide Operations
• Use Inheritance
• Understood by Developers

40
Types Benefits

• Application Template
• Data Model
• Data Structure
• System Architecture
• Process Model
• Process Definition
• Prototype
• Plan Skeleton
• User Interface Skeleton/GUI
• Process Skeleton
• Utility Components
• Security Process
• Etc.

• Organizational Perspective
• Shorten Development Time
• Reduce Costs
• Increase Competitiveness
• Personnel Perspective
• Increase Productivity
• Customer Perspective
• Achieve Greater User Satisfaction Through the
  Production of More Flexible Products

41
Component-Based Development Process
TOP-DOWN To determine what is needed to satisfy
this need.
OTHERS Consider the similarity among concurrent
projects.
FUTURE Consider the possibility of reusing in
future projects.
BOTTOM-UP To determine what is available to
satisfy this need.
42
Supplier /Consumer Model
43
Component
Specification How to Use
Interfaces
Implementation The Code
Executable The Bean
44
Complexity of Component
Components as Assets can Grow
45
Design Patterns

• Emerged as the Recognition that in
  Object-Oriented Systems Repetitions in Design
  Occurred
• Component at Design Level
• Gained Prominence in 1995 with Publication of
  Design Patterns Elements of Reusable
  Object-Oriented Software, Addison-Wesley
• descriptions of communicating objects and
  classes that are customized to solve a general
  design problem in a particular context
• Akin to Complicated Generic
• Usage of Patterns Requires
• Consistent Format and Abstraction
• Common Vocabulary and Descriptions
• Simple to Complex Patterns Wide Range

46
The Observer Pattern

• Utilized to Define a One-to-Many Relationship
  Between Objects
• When Object Changes State all Dependents are
  Notified and Automatically Updated
• Loosely Coupled Objects
• When one Object (Subject an Active Object)
  Changes State than Multiple Objects (Observers
  Passive Objects) Notified
• Observer Object Implements Interface to Specify
  the Way that Changes are to Occur
• Two Interfaces and Two Concrete Classes

47
The Observer Pattern
48
2000s Web/Distributed Applications

• Distributed Computing/Applications are
• Systems of Systems
• Interoperation of New Existing Applications
• Legacy, Databases, COTS, New Clients, etc.
• Network Centric Environment
• Multi-Tier Solutions
• Distributed Computing Applications must
• Manage, Control, Access, and Modify Data
• Allow Humans to Interact with Data
• Provide High-Availability and Performance
• Evolvable Over Time
• Present Future Systems Exhibit All of These
  Characteristics and More!

49
What is a Distributed Application?
Network Centric Environment
System of Systems
High-Availability
Performance
Heterogeneity Hardware OS, PLs
Dynamic Environment
Increase Productivity
New/Innovative Information Use
Transparent Interoperation
50
Another View Todays Reality

• Premise Artifacts - set of
• DB, Legacy, COTS, GOTS, Each w/ API
• Premise Users
• New and Existing
• Utilize Artifact APIs
• Distributed Application, DA
• Artifacts Users
• What are the Issues?
• How Do they Interact?
• Heterogeneity
• Security Concerns
• Different Programmatic Models
• Etc. Etc. Etc.

Database
COTS
Legacy
Legacy Client
GOTS
NETWORK
GOTS Client
Legacy
Database
Database Client
COTS Client
51
Why is Distributed Computing Needed?

• Todays Environments Contain Applications
• Created with Multiple Prog. Languages
• Executing on Heterogeneous Platforms
• Locally and Geographically Distributed
• Distributed Computing Applications Must
• Allow Seamless and Transparent Interoperation
• Provide Tools for Engineers and Users
• Result Inter-Operating Environment
• Utilize Information in New/Innovative Ways
• Leveraged to Increase Productivity
• Support Diverse User Activities
• Dynamically Respond to Changes

52
Striving for New Techniques/Technologies

• We Must Diverge from Business as Usual
• C Programming with RPC
• Customized Development without Reuse
• Solutions that Arent Extensible and Evolvable
• Cobbling Together Solutions w/o Method or Reason
  is Unacceptable and Doomed to Fail!
• We Must Face Todays Realities
• Legacy Code is Fact of Life
• New Technologies Offer New Challenges
• Adopt to Leverage Their Benefits
• We Must Draw Careful Balance to Opt for Mature
  Technologies While Targeting Emerging
  Technologies with Potential!

53
Who are the Players?

• Stakeholders
• Software Architects (Requirements)
• System Designers (Solutions)
• Application Builders (Implementation)
• Stakeholders Striving to Provide
• System Interaction and Information Exchange
• Utilization of Existing Applications in New and
  Innovative Ways
• End-Users at Various Skill Levels and with
  Specific and Limited Access Requirements
• Novice vs. Adept vs. Expert
• Who Uses What When and for How Long?

54
Why a Distributed Application?

• Reasons
• Data used is Distributed
• Computation is Distributed
• Application Users are Distributed
• 2 Key Issues for Solution
• Platform-Independent Models and Abstraction
  Techniques
• Hide Low-Level Details
• Provide a Well-Performing Solution
• Works Today and Tomorrow!

Shared Objects

• Easy to Re-use
• Easy to distribute
• Easy to maintain

55
Java Client with Wrapper to Legacy Application
Java Client
Interactions Between Java Client and Legacy Appl.
via C and RPC C is the Medium of Info.
Exchange Java Client with C/C Wrapper
Java Application Code
WRAPPER
Mapping Classes
JAVA LAYER
NATIVE LAYER
Native Functions (C) RPC Client Stubs (C)
Legacy Application
Network
56
COTS and Legacy Application to Java
COTS Application
Legacy Application
Java Application Code
Java Application Code
Native Functions that Map to COTS Appl
Native Functions that Map to Legacy Appl
NATIVE LAYER
NATIVE LAYER
JAVA LAYER
JAVA LAYER
Mapping Classes
Mapping Classes
JAVA NETWORK WRAPPER
JAVA NETWORK WRAPPER
Network
Java Client
Java Client
Java is Medium of Info. Exchange - C/C Appls
with Java Wrappers
57
Three-Tier Example
58
Four-Tier Architecture Example
59
Chapter 1 - Summary

• Computing is Pervasive Throughout Society!
• Software Engineering has Not Kept Pace as a
  Discipline to Hardware Advances
• CPU Speed (and Multi-Processors)
• Memory Size
• 1982 PDP 11/44 with 256K
• 1993 Sun 4 with 32M
• 1997 Sun Ultra with 64M/PC with 32 M
• 1998 Suns and PCs with 128M
• 2006 PCs with 1-2Gigabytes
• Disk Capacity
• 1982 60M with 2 by 3 by 3 Footprint
• 1993 200M inside your PC
• 1997 2 to 4 G inside your PC
• 1998 8 or more G inside your PC
• 2006 PCs with 160G, NW Storage Devices, etc.

60
Chapter 1 - Summary

• Software Becoming More Complex and Appearing in
  More and More Places (Embedded Computing)
• Software Engineering Must Evolve to Embrace
  Engineering Concepts, Approaches, and Rigor!
• Technology
• Component-Based, Distributed, Web, etc.
• Software Engineering for
• Education
• Software Engineering MS Degrees (Now)
• Software Engineering BS Degrees (On Table)
• Licensing of Software Engineers (Texas?)
• Provide Rules for Software Engineering
• Chapter 2 - What are Qualities of Software?
• Chapter 3 - What are Principles of Software?