1 cse 2102 cse 2102 chapter 1: software engineering overview prof. steven a. demurjian computer...
TRANSCRIPT
1
CSE
2102
CSE
2102
Chapter 1: Software Engineering Overview Chapter 1: Software Engineering Overview
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)
Material for course thanks to:Prof. Swapna Gokhale
2
CSE
2102
CSE
2102 Introduction to Software Engineering What is a Program? What is History of Software/Computing What is Software Engineering? What Do Software Engineers Do? How is Software Engineered (Process)? What are Issues and Challenges for SW Engrg? Software Engineering vs. Computer Science?
Designing/Building Systems for Today/Tomorrow Recall CSE1102: Object Oriented Design/Devel.
Abstract Data Types (ADTs), Core and Advanced Object-Oriented Concepts, Benefits of OO
Component-Based Design & Design Patterns The Unified Modeling Language (UML)
Overview of Chapter 1
3
CSE
2102
CSE
2102
What is a Program?
Plan or a routine for solving a problem on a computer Sequence of instructions used by a computer to do a
particular job or to solve a given problem Set of statements to be used directly or indirectly in a
computer in order to bring about a certain result
ProblemDomainProblemDomain
SolutionDomainSolutionDomain
PR0GRAM
PR0GRAM
Program serves as the interface between the problem domain and the solution domain.
4
CSE
2102
CSE
2102
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), Fortran, C and C++!
Client vs. Server Software (Javascript) Database Management Systems/Applications New Languages: Java, Perl, Python New Mobile Platforms: Android, iOS Standards: XML, RDF, OWL, etc.
5
CSE
2102
CSE
2102
Definition of Software Engineering IEEE definition:
The application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software.
Roger S. Pressman’s definition (UConn PhD): Software engineering is the technology that
encompasses a process, a set of methods and an array of tools. (Software Engineering: A Practitioner’s Approach)
Parnas’s definition: Multi-person construction of multi-version
software (Parnas 1978)
6
CSE
2102
CSE
2102
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
7
CSE
2102
CSE
2102
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)
8
CSE
2102
CSE
2102
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
9
CSE
2102
CSE
2102
Software Engineering - Historically “Early Days”
1950’s Programmers Wrote Programs Early 1960’s - Very Large Software Projects
Constructed by “Experts” Mid-Late 1960’s - Advent of Large Commercial
Software Applications Large Systems Involved Teams of Individuals Coining the Term “Software Engineering”
Towards a Software Engineering Discipline Individuals Couldn’t see “Big Picture” Increase in Communication Time Personnel Changes Impact on Productivity
SE: Management, Organization, Tools, Theories, Methodologies, Techniques, etc.
10
CSE
2102
CSE
2102
Computing: A Historical Perspective Early era of computer/software evolution:
General-purpose hardware became commonplace Software was custom-designed for each
application with a relatively limited distribution Product software (that is, programs to be sold to
one or more customers) was in its infancy Second era of computer/software evolution:
Multiprogramming and multi-user systems introduced human-machine interaction
Real-time systems could collect, analyze and transform data from multiple sources
Advances in on-line storage led to the first generation of database management systems
Use of product software and the advent of “software houses”
11
CSE
2102
CSE
2102
Computing: A Historical Perspective Third era of computer/software evolution:
Distributed system greatly increased the complexity of computer-based systems
Advent and widespread use of microprocessors Computers readily accessible to the public at large,
rather than privilege of chosen few Fourth era of computer/software evolution:
Moved away from individual computers and computer programs and toward the collective impact of computers and software
Powerful desk-top machines controlled by sophisticated operating systems, networked locally and globally, and coupled with advanced software applications
Internet exploded and changed the way of life and business
12
CSE
2102
CSE
2102
Computing: A Historical Perspective Are we in a Fifth Era of Computing Today?
Mobile Computing Scripting Languages Platform Independent Environments
Sencha Touch (html5) and Titanimum (Javascript) Touch Screens, Interactive Computing Mobile Computing
Phones, Tablets, Watches, Glasses, What’s Next? Wireless Anywhere Access Pervasive into Wide Range of Products from Cars
to TVs to Microwaves What will be the Next Great Improvement?
13
CSE
2102
CSE
2102
Computing: A historical perspectiveComputing: A historical perspective
1950 1960 1970 1980 1990 2002
Early era
•General-purpose hardware.
•Custom software
Second era
•Multi-programming/multi-user•Database Management Systems
•Software houses
Third era
•Distributed systems•Microprocessors
•PC-based systems
Fourth era
•Powerful desktops•Internet
•Software apps.
Fifth Era?
14
CSE
2102
CSE
2102
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 Currently 4.16 million IT Professional with
Expected Growth of 22% by 2020! 30% by 2020! http://www.bls.gov/ooh/Computer-
and-Information-Technology/Software-developers.htm
15
CSE
2102
CSE
2102
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
16
CSE
2102
CSE
2102
Programmer vs. software engineer Programmer
Individual with good skills Knowledge on data structures, algorithms Fluent in several programming languages May lack formal training Minimal exposure to CS
Programming-in-the-small Is Mobile Computing Programming in the Small?
Breeding New Type of Developers One Person Development Ability to be Widely and Easily Distributed Changing the Face of Computing
17
CSE
2102
CSE
2102
Programmer vs. software engineer Programming skill is not enough Software engineering involves “programming-in-the-
large” Understand requirements and write specifications
Derive models and reason about them Master software Operate at various levels of abstraction Member of a team:
Communication skills Management skills
18
CSE
2102
CSE
2102
What Does a Software Engineer Do? Work as professionals in the software industry:
Design Sections of much larger systems Written by many professionals over years Tested and Maintained by different subset of
Individuals Require knowledge in many fields of computer
science and the application domain Hard to find Application with GUI and/or Database
Rarely work in isolation Multiple constituencies to whom the professional
Project manager Clients Users Subsequent generations of professionals
19
CSE
2102
CSE
2102
What are Software Engineering Processes? Software Production Process Models
Focus on the “How” of Software Development Stages, Phases, Steps: Methodology
Varied Process Models Waterfall Model (oldest)/Evolutionary Model Transformation Model/Spiral Model UML Unified Process/Agile Model (newest)
Other Process Issues Configuration Management/ Standards
Production Models Focus on the Software Lifecycle Emphasizing the Process from Start to Finish
20
CSE
2102
CSE
2102
Waterfall Process ModelWaterfall Process Model
Requirements Analysis andSpecification
Design andSpecification
Coding andModule Testing
Integration andSystem Testing
Delivery and Maintenance
50 %50 %
50 %50 %
What is Major Disadvantage?
Grandfather of All ModelsGrandfather of All Models
21
CSE
2102
CSE
2102
What are Software Requirements?What are Software Requirements?
22
CSE
2102
CSE
2102
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
23
CSE
2102
CSE
2102
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
24
CSE
2102
CSE
2102
What are Issues and Challenges? State of the Practice:
0
10
20
30
40
50
60
Cost overrun Successful Cancelled
Source: The Standish Group, 1994•Successful projects (16.2%)
- Delivered fully functional on time and on budget.•Challenged (52.7%)
- Deliver less than full functionality, over-budget and late.•Impaired (31.1%)
- Cancelled during development.
25
CSE
2102
CSE
2102
Pervasiveness of Software Software is an important growing component of
several systems in diverse domains : Power trains of GM cars contain 30 lines of code (LOC) Electric razors contain 2 KLOC TV sets contain 500 KLOC. Space shuttles and military aircraft systems thousands of
KLOC. Demand for larger software systems is exponential:
F4 had no digital computer and software (Early 70’s) F16A had 50 digital processors and 135 KLOC (Late 70’s) F16D had 300 digital processors and 236 KLOC (Late
80’s) B-2 has over 200 digital processors and 5000 KLOC
What will be Impact of Mobile Computing? Smartphone/Tablet Hybrid? Will Laptops Dissappear?
26
CSE
2102
CSE
2102
Software Development ProblemsSoftware Development Problems
Software costs are increasing as hardware costs continue to decline.
•Hardware technology has made great advances.•Simple and well understood tasks are encoded in hardware.•Least understood tasks are encoded in software•Demands expected of software are growing•Size of the software applications is also increasing.
Software costs
Hardwarecosts
Time
Hardware costs vs. Software costs
27
CSE
2102
CSE
2102
Software Development ProblemsSoftware Development Problems
Software development times are getting longer and longer andmaintenance costs are getting higher and higher
3%8%
7%
15%
67%
Requirements -- 3%Design -- 8%Implementation -- 7%Testing -- 15%Maintenance -- 67%
•Most of the money and effort spent in testing and maintenance.•85% of errors are introduced during requirements analysis and design.
28
CSE
2102
CSE
2102
Software Development ProblemsSoftware Development Problems
0
10
20
30
40
50
60
70
80R
equir
em
ents
Desi
gn
Imple
menta
tion
Test
ing
Main
tenance
Cost
Cost to fix an error increases as it is found later and later in the software lifecycle.
Relative costs to fix errorsRelative costs to fix errors
29
CSE
2102
CSE
2102
Software Development Problems Denver Automatic Baggage Handling System:
Opening delayed for 2 years. $27 million cost overrun. $360 million delay cost.
Outages of AT&T long distance switches: Network unusable for about 9 hours on Jan 15,
1999 First major network problem in AT&T’s network in
114 years. Ariane 5 launch explosion, 4 June 1996: - http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html NIST estimates that the US economy loses
approximately $59.5 billion of 0.6% of the GDP due to software failures
30
CSE
2102
CSE
2102
What software engineering is and is not.. Software engineering is concerned with “engineering”
building and modifying practical software systems: On time Within budget Meeting quality and performance standards Deliver the features desired/expected by the
customer Software engineering is not..
Just building small or new systems Hacking or debugging until it works Easy, simple, boring or even pointless!
These are the issues that haven’t really surfaced in learning to program
Transformation/translation of a program to “software”
31
CSE
2102
CSE
2102
Program to Product TransitionProgram to Product Transition
•Designed for generality.•Documented for users of varied ability.•Documented for continued maintenance by persons other than the original author.•Thoroughly tested and test cases archived.•Archived test cases are used to verify that changes do not break existing functions.Ex: Program can handle different currencies
•Multiple, interacting programs.•Operating in complex hardware and data environment.•Larger and more complex than a program.•Require more work in interface design and module integration.Ex: Transform the program to interact withDBMS and work for a small company’s payroll and accounts payable.
•Combines the additional concerns of program products and programming systems.•Large product development enterprises involving extensive design effort to ensure consistent and reliable integration.•Thorough, multilayered documentation.•Careful planning and execution of testing and maintenance activity. Ex: Integrated inventory, billing and ordering with accounts payable.
32
CSE
2102
CSE
2102
Program to Software Transformation Difficult part in designing any software system is
usually not the coding of the software Executable object is not the only artifact of
importance. Key problem is ensuring conceptual integrity of the
design Advances in software engineering technology has
eased the implementation Real difficulty is developing and maintaining the
unifying concept during the initial development and subsequent revisions
Software engineering is not about individual programming but about a structured approach for groups to manage complexity and change.
33
CSE
2102
CSE
2102
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
34
CSE
2102
CSE
2102
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
35
CSE
2102
CSE
2102
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
36
CSE
2102
CSE
2102
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
37
CSE
2102
CSE
2102
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
38
CSE
2102
CSE
2102
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, Bioinforamtics,
Genomics SWE and Financial Sector
Banking, ATM Networks, Electronic Commerce, Funds Transfers, Program Trading, Stock and Brokerage Houses, etc.
39
CSE
2102
CSE
2102
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 From Web to Mobile Platforms
Tracing the History Abstract Data Types (ADTs) - 1970s Object-Oriented Paradigm - 1980s Component-Based D & D – 1990s Web-Based/Distributed Computing – 2000s Mobile/Touch Screen Computing – 2008- present
40
CSE
2102
CSE
2102
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!
41
CSE
2102
CSE
2102
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
Integration of Past, Present and Future Information via Intranet and Internet Access
Emergence of eXtensible Markup Language (XML) as de facto standard for Information Sharing/Exchange
42
CSE
2102
CSE
2102
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?
43
CSE
2102
CSE
2102
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.
44
CSE
2102
CSE
2102
Abstract Data Types (ADTs) Consider the following Example Stack ADT:
PublicInterface
User
PUSHPOPTOP
EMPTY
Private Implementation
DesignerHead: Int;ST: Array[100] of Int;
Push(X Int)…End;
Int Pop()…End;
TOP
5
1015
20
PUSH
5
20 15 10 5
20 15 10 5
ST
45
CSE
2102
CSE
2102
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
46
CSE
2102
CSE
2102
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
47
CSE
2102
CSE
2102
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 Object’s Method Invoked
48
CSE
2102
CSE
2102
An Example Employee ClassAn Example Employee Class
Class Employee {
}
//Hidden ImplementationPrivate: //Instance Vars char[30] name; float salary;//Public InterfacePublic: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s);
Main(){//Declare ObjectsEmployee emp1(Steve,100.0);Employee emp2(Lois, 120.0);
//Pass Messages//Invoke Methodsemp1.print_name();emp1.print_salary();emp2.update_salary(10);emp2.print_name();emp2.print_salary();}
What’s Output of Main()?
Steve100.0Lois130.0
Conclusion: Each Object (emp1,emp2) has Own Independent State that is Accessible via Shared Public Interface of Class
49
CSE
2102
CSE
2102
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
50
CSE
2102
CSE
2102
Advanced Object-Oriented Concepts Inheritance
Controlled Sharing of Between ClassesGeneralization 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)
51
CSE
2102
CSE
2102
A Quick Look at InheritanceA Quick Look at Inheritance
Person Name, SSN
Print_Info()
Faculty::Employee Rank
Promote_Fac()
Dean::Employee School
Employee::Person Dept, Salary
Update_Salary()
Student::Person Dorm, GPA
Print_Transcript
GeneralizationSpecialization
Supertype, Superclass, Parent Class, Base ClassSubtype, Subclass, Child Class, Derived Class
Descendants, Ancestors, Siblings
52
CSE
2102
CSE
2102
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.
53
CSE
2102
CSE
2102
What Can Be a Class?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 Represent a Functional Action that Performs a Well-Defined Task with Minimal Internal StateWell-Defined Task with Minimal Internal State
For Example, Supermarket UPC Scan, Automobile For Example, Supermarket UPC Scan, Automobile Diagnostic Analyzer, etc.Diagnostic Analyzer, etc.
54
CSE
2102
CSE
2102
What Can Be a Class?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 SystemInteraction Between User and System For Example, Supermarket Cashier, Browser For Example, Supermarket Cashier, Browser
Interface, etc.Interface, etc.
55
CSE
2102
CSE
2102
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
56
CSE
2102
CSE
2102
1990s – Component Based D & D ADTs as Unit of Abstraction/Conceptualization Classes are OO Equivalent of ADTs However, in Past 15Years
Computing Power has Exploded Application Complexity has Increased Classes are Part of Inheritance Hierarchy Inheritance Hierarchy Part of Application Class
Library In Past 15 years
Emergence of Java (and.NET) andWrite Once, Run Everywhere
Emergence of Java Beans Component-Based Development Tools
57
CSE
2102
CSE
2102
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
58
CSE
2102
CSE
2102
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
59
CSE
2102
CSE
2102
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
60
CSE
2102
CSE
2102
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
61
CSE
2102
CSE
2102
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
62
CSE
2102
CSE
2102
Component-Based Development ProcessComponent-Based Development Process
TOP-DOWN:To determine what is needed
to satisfy this need.
BOTTOM-UP:To determine what is available to
satisfy this need.
OTHERS:Consider the similarity
among concurrent projects.
FUTURE:Consider the possibility of reusing in future projects.
63
CSE
2102
CSE
2102
SUPPLY Build New
Wrap Existing Buy
CONSUME Assemble
Applications
MANAGE Publish
Subscribe Catalog Browse
Supplier /Consumer ModelSupplier /Consumer Model
64
CSE
2102
CSE
2102
SpecificationSpecificationHow to UseHow to Use
ImplementationImplementationThe CodeThe Code
ExecutableExecutableThe “Bean”The “Bean”
InterfacesInterfaces
ComponentComponent
65
CSE
2102
CSE
2102
Components as Assets can GrowComponents as Assets can Grow
Complexity of ComponentComplexity of Component
66
CSE
2102
CSE
2102
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
67
CSE
2102
CSE
2102
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
68
CSE
2102
CSE
2102
The Model View Controller PatternThe Model View Controller Pattern
69
CSE
2102
CSE
2102
The Observer PatternThe Observer Pattern
70
CSE
2102
CSE
2102
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!
71
CSE
2102
CSE
2102
JavaClient
JavaClient
LegacyClient
DB Client
COTSClient
What is a Distributed Application?What is a Distributed Application?
LegacyDatabase
Server
Legacy
COTSServer
Database
COTS
Network Centric Environment
High-AvailabilityPerformanceHeterogeneity Hardware OS, PLs
Transparent Interoperation New/Innovative Information Use
Increase ProductivityDynamic
Environment
System of Systems
72
CSE
2102
CSE
2102
Another View – Today’s Reality
Legacy
Legacy
COTS
GOTS
Database
Database
NETWORK
JavaClient
GOTSClient
LegacyClient
DatabaseClient
COTSClient
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.
73
CSE
2102
CSE
2102
Why is Distributed Computing Needed? Today’s 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
74
CSE
2102
CSE
2102
Striving for New Techniques/Technologies We Must Diverge from Business as Usual
C Programming with RPC Customized Development without Reuse Solutions that Aren’t Extensible and Evolvable Cobbling Together Solutions w/o Method or
Reason is Unacceptable and Doomed to Fail! We Must Face Today’s 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!
75
CSE
2102
CSE
2102
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?Who Uses What When and for How Long?
76
CSE
2102
CSE
2102
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!
• Easy to Re-use• Easy to distribute• Easy to maintain
77
CSE
2102
CSE
2102
Java Client with Wrapper to Legacy ApplicationJava Client with Wrapper to Legacy Application
LegacyLegacyApplicationApplication
NetworkNetwork
Java ClientJava Client
Java Application CodeJava Application Code
WRAPPERWRAPPER
Mapping ClassesMapping Classes
JAVA LAYERJAVA LAYER
NATIVE LAYERNATIVE LAYER
Native Functions (C++)Native Functions (C++)RPC Client Stubs (C)RPC Client Stubs (C)
Interactions Between Java ClientInteractions Between Java Clientand Legacy Appl. via C and RPCand Legacy Appl. via C and RPC
C is the Medium of Info. ExchangeC is the Medium of Info. Exchange
Java Client with C++/C WrapperJava Client with C++/C Wrapper
78
CSE
2102
CSE
2102
COTS and Legacy Application to JavaCOTS and Legacy Application to Java
NetworkNetwork
Java Application CodeJava Application Code
Mapping ClassesMapping Classes
NATIVE LAYERNATIVE LAYER
JAVA LAYERJAVA LAYER
Native Functions that Native Functions that Map to COTS ApplMap to COTS Appl
Java ClientJava Client Java ClientJava Client
Java Application CodeJava Application Code
Mapping ClassesMapping Classes
NATIVE LAYERNATIVE LAYER
JAVA LAYERJAVA LAYER
Native Functions that Native Functions that Map to Legacy ApplMap to Legacy Appl
COTS ApplicationCOTS Application Legacy ApplicationLegacy Application
Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers
79
CSE
2102
CSE
2102
Three-Tier ExampleThree-Tier Example
80
CSE
2102
CSE
2102
Four-Tier Architecture ExampleFour-Tier Architecture Example
81
CSE
2102
CSE
2102
Today’s and Tomorrows Applications?Today’s and Tomorrows Applications? Mobile Computing is Changing the World! Computing Power and Versatility Unmatched for
Price $700 Tablet with 128G, and 500 Phone with 32G
In 1987, Sun Workstation (black and white, local system drive, files remote) - $20,000
Is Java’s Write Once Run Anywhere Still Relevant? Consider Titanium Platform http://www.appcelerator.com/
Cross Platform Apps from Single Javascript
Codebase iOS, Android, Windows, BlackBerry, HTML5 Dramatically Changes Game Why Design and Develop Anyway Else?
82
CSE
2102
CSE
2102
Chapter 1 - Summary Computing is Pervasive Throughout Society! Software Engineering Behind 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 2013 Tablets with 128 Gigabytes
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. 2013: Gigabyte Drives a Norm/Memory Cards vs. Drive
83
CSE
2102
CSE
2102
Chapter 1 - Summary Critical aspects of our lives depend on software Software development lacks the rigor and discipline of
mature engineering disciplines: Software engineering aims to bring discipline/rigor to
the building and maintenance of software systems Study of software engineering focuses on three key
elements: process, methods and tools Software products are often expected to satisfy various
non functional requirements: Relative priorities of these requirements depend on
the nature of the application. May or may not be able to satisfy all the
requirements, tradeoffs may be necessary.
84
CSE
2102
CSE
2102
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, Mobile, etc. Embedded (TVs, Refrigerators, etc.)
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?