Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 1: Software Engineering Overview

Similar presentations

Presentation on theme: "Chapter 1: Software Engineering Overview"— Presentation transcript:

1 Chapter 1: Software Engineering Overview
Prof. Steven A. Demurjian Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT (860) 486 – 4818 (860) 486 – 3719 (office) Material for course thanks to: Prof. Swapna Gokhale

2 Overview of Chapter 1 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)

3 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 P R G A M Problem Domain Solution Domain Program serves as the interface between the problem domain and the solution domain.

4 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 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) Several definition. Look at the last one. It recognizes that a software product is much more complex and beyond the grasp of a single individual. As a result, a number of people are expected to work on the pieces of a software product in a cooperative fashion. Also, some of these people may leave the project, and may be replaced by newer engineers, in which case, the project has to lose the know how of that engineer. Also, a software product may have many versions and we need to manage these versions. Thus, SE is also a management activity in addition to the implementation activity.

6 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 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 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 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 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” Early era – a single person wrote software for his/her own use. Usually, a mathematical problem was solved. The problem was well understood, and well within the grasp and comprehension capability of a single individual. Second-era – product software, that is now the user of the software and the developer was different. Also, software development organizations started producing applications with a general appeal, rather than applications that were tailored to the needs of a specific party. For example, word processing applications. Also, new storage capabilities led to the development of DBMS to store data efficiently, and to manage multiple people accessing the data simultaneously.

11 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 Distributed system technology, a computer application need not run on a single computer, but could run on a collection of computers, and exploit the power offered by the collection. So even if a single computer was not powerful enough to solve a problem, a collection of computers might be. Also, if we were to get a single computer with the necessary power, it may be expensive, but a collection might not be. Also, the economic considerations allowed individual users to have computers. Fourth era – networked computers, communicating over LANs and WANs, can access data and content miles and miles away. Exploision in the scope, and breadth of software apps.

12 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 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? Distributed system technology, a computer application need not run on a single computer, but could run on a collection of computers, and exploit the power offered by the collection. So even if a single computer was not powerful enough to solve a problem, a collection of computers might be. Also, if we were to get a single computer with the necessary power, it may be expensive, but a collection might not be. Also, the economic considerations allowed individual users to have computers. Fourth era – networked computers, communicating over LANs and WANs, can access data and content miles and miles away. Exploision in the scope, and breadth of software apps.

13 Computing: A historical perspective
Fifth Era? Powerful desktops Internet Software apps. Fourth era Distributed systems Microprocessors PC-based systems Third era Multi-programming/multi-user Database Management Systems Software houses Second era General-purpose hardware. Custom software Early era 1950 1960 1970 1980 1990 2002

14 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 Perspective Conception Design Development Integration Distribution Documentation Maintenance Evolution Extension Software Engineering/Computer Science Growth Currently 4.16 million IT Professional with Expected Growth of 22% by 2020! 30% by 2020!

15 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 Programmer vs. software engineer
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 The programmer is typically expected to write programs to solve well-defined and small problems. He must be trained in data structures, and algorithms, and must be fluent in several programming languages. May or may not be trained or exposed to CS. Because the task is well understood by a single person, it is often known as programming in the small.

17 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 In addition to the programming skills, the software engineer must posses many other skills. He must be able to interface with the users of the system and understand what it is that they expect of the system. Also, he must be able to translate the vague and ambiguous requirements specified by the user into something precise which gets rid of all the ambiguities. Also, he must be able to develop models of the system. He must understand what factors should be incorporated into the models, and what factors may be safely ignored. Also, he must operate at various levels of abstraction. Also, he must possess interpersonal skills, and the ability to cooperate and work as a part of a team.

18 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 Programmers are involved in developing solutions to small problems, students working in course projects. The time frame of the project is semester long, that is, the project is short lived and does not live much longer than a semester. Each student rarely has to interact with other people. Also, the knowledge required to complete the project is something that the students have already acquired in prior courses. The student is expected to satisfy only himself or in some cases the course instructor. On the other hand, an SE almost always works on a small piece of a big system. He/She very rarely has the luxury of writing something on his/her own, but most often has to understand and modify the code written by the other SE. In addition, CS fundamentals are essential, but the knowledge of the domain from which the problem belongs is also essential. This domain could be a related engineering discipline, or something even non engineering such as social sciences, finance, etc. The SE must have interpersonal skills, and must be able to cooperate and communicate in a team. The professional is responsible to satisfy the expectations of his boss, the clients who will buy the software application, and the users who will use the software application. Also, the SE has professional responsibility to document his actions so that the life of subsequent professionals is easier.

19 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 Waterfall Process Model
Grandfather of All Models Requirements Analysis and Specification What is Major Disadvantage? Design and Specification 50 % TIME & COST Coding and Module Testing Integration and System Testing Delivery and Maintenance 50 %

21 What are Software Requirements?

22 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 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 What are Issues and Challenges?
State of the Practice: 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 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 Software Development Problems
Software costs are increasing as hardware costs continue to decline. Hardware costs vs. Software costs 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. Hardware costs Software costs Previously h/w costs dominated, s/w costs were trivial. But now software costs dominate. The total cost of the applications on your PC exceeds the cost of the hardware on which those applications sit. Because of the flexible nature of the software (can be changed easily), our tendency is to encode the least understood, and uncertain tasks in software, whereas the simple and well understood tasks in hardware. As a result, the size of the software applications grows, and these applications become inherently complex, increasing the cost even further. Time

27 Software Development Problems
Software development times are getting longer and longer and maintenance costs are getting higher and higher 3% 8% 7% 15% 67% Requirements % Design % Implementation -- 7% Testing % Maintenance % It takes a long time to understand the requirements of a software system, and then subsequently design and implement the software system. However, it takes much longer to test the system to ensure that it satisfies the user requirements. Software systems live much longer than is originally expected. In fact, a number of applications which were developed in the 1970s (often known as legacy applications) are being used even today. However, these applications have undergone many changes or have evolved. The changes made to the software after it has been released is referred to as maintenance of the software. Today, software maintenance is the most time and cost consuming activity of the software application. If the original requirements are not well understood, then that increases the need for maintenance even further, since it is discovered after release that the software application does not perform the intended tasks. In fact, over 80% of the errors that need to be fixed during testing and during maintenance is the result of poorly understood requirements. Most of the money and effort spent in testing and maintenance. 85% of errors are introduced during requirements analysis and design.

28 Software Development Problems
Relative costs to fix errors Cost to fix an error increases as it is found later and later in the software lifecycle. Cost It pays to discover errors sooner than later. If an error is discovered in the requirements phase, then, it is much less costly to fix an error, than when an error is discovered after the software system has been put into operation. Misunderstood requirements is the most common cause of error in a software product, and is often not discovered until the software system has been released and has been used by the customer. Design Testing Maintenance Requirements Implementation

29 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: - NIST estimates that the US economy loses approximately $59.5 billion of 0.6% of the GDP due to software failures

30 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” The primary concern of software engineering is to facilitate the creation of large and complex software systems that are delivered to the customers as planned, and within the original cost estimates. Also, these systems must be capable of providing the functionality expected by the user, as well as meet the non functional requirements. It must be relatively easy to perform maintenance on the software system. All the design decisions must be well documented, and the system must be easy to use for the users, and easy to understand by the developers who will be subsequently working to modify the system. SE is often confused with programming. However, the main task of programming is to explore and build new systems. These new systems are small enough that they could be built by a single programmer. The programmer may spend a number of sleepless nights hacking until the program works. As a result, most programmers often have this misconceived notion that if they know how to program, then the study of software engineering is quite trivial and a waste of time. However, in SE one has to deal with issues that the programmers haven’t been exposed to. Thus, SE seeks to transform a program into a software product.

31 Program 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 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. 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 with DBMS and work for a small company’s payroll and accounts payable. What does it take a program to be transformed into a program product? A program may be written by a single programmer for his or her own use. He may never intend to share it with anybody, or make it general. However, to transform a program into a program product, the program must solve the general problem rather than solving the specific instance of the problem. Also, how the program might be used must be documented taking into consideration that it could be used by users of varied ability, namely, experts, novice users, and intermediate users. Also, the design decisions must be documented so that code modifications which are inevitable for maintenance activities may be performed by other people other than the original author. The test cases used for testing the program must be archived so that they could be used later to make sure that any modifications do not break the existing functionality. This takes 3 times the effort of writing a simple program. Transforming a program to a programming system adds the feature of making the program interact with other programs. When you want a program to talk to other programs, the interfaces between these two programs must be carefully designed. Also, these multiple programs must be integrated so that they work together. This takes 3 times the effort of developing a program. In order to transform a program to a programming system product, it must satisfy the requirements of both a program product and a programming system. The effort taken is 9 times as much.

32 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. We saw that the transformation of a program to a product requires 3 times as much effort. Where does this effort go? The coding or implementation is pretty much the same in case of a program and a software product which performs the same task. However, for a product, a considerable amount of effort needs to be spent in the design of a product so that it is easily maintainable. Also, the design decisions, as well as the code needs to be documented thoroughly, so that future evolutions of the product by other personnel can be easily facilitated. Remember, that a software product may have a long life cycle and may require several people to work on the product. Thus, another definition of SE is:

33 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 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 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 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 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 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 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) s Object-Oriented Paradigm s Component-Based D & D – 1990s Web-Based/Distributed Computing – 2000s Mobile/Touch Screen Computing – present

40 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 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 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 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 Abstract Data Types (ADTs)
Consider the following Example Stack ADT: Public Interface User PUSH POP TOP EMPTY Private Implementation Designer Head: Int; ST: Array[100] of Int; Push(X Int) End; Int Pop() TOP 5 10 15 20 PUSH 20 15 10 5 ST

45 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 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 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 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(); emp2.update_salary(10); emp2.print_name(); emp2.print_salary(); } //Hidden Implementation Private: //Instance Vars char[30] name; float salary; //Public Interface Public: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s); What’s 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

49 Modules vs. ADTs/Classes
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 Advanced Object-Oriented Concepts
Inheritance Controlled Sharing of Between Classes Generalization 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 A Quick Look at Inheritance
Person Name, SSN Print_Info() Specialization Generalization Employee::Person Dept, Salary Update_Salary() Student::Person Dorm, GPA Print_Transcript Faculty::Employee Rank Promote_Fac() Dean::Employee School Supertype, Superclass, Parent Class, Base Class Subtype, Subclass, Child Class, Derived Class Descendants, Ancestors, Siblings

52 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 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.

54 What Can Be a Class? Interaction Between User and System
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.

55 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 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) and Write Once, Run Everywhere Emergence of Java Beans Component-Based Development Tools

57 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 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 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 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 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 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.

63 Supplier /Consumer Model
SUPPLY Build New Wrap Existing Buy CONSUME Assemble Applications MANAGE Publish Subscribe Catalog Browse

64 Component Specification How to Use Interfaces Implementation The Code
Executable The “Bean”

65 Complexity of Component
Components as Assets can Grow

66 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 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 The Model View Controller Pattern

69 The Observer Pattern

70 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 What is a Distributed Application?
System of Systems Network Centric Environment Heterogeneity Hardware OS, PLs Performance High-Availability Java Client Legacy DB Client COTS Legacy Database Server COTS Dynamic Environment Increase Productivity New/Innovative Information Use Transparent Interoperation

72 Another View – Today’s 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 Java Client GOTS NETWORK GOTS Client Legacy Database Database Client COTS Client

73 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 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 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?

76 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 Java Client with Wrapper to Legacy Application
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

78 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 Network Java Client Java Client Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers

79 Three-Tier Example

80 Four-Tier Architecture Example

81 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 Cross Platform Apps from Single Javascript Codebase iOS, Android, Windows, BlackBerry, HTML5 Dramatically Changes Game Why Design and Develop Anyway Else?

82 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 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 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?

Download ppt "Chapter 1: Software Engineering Overview"

Similar presentations

Ads by Google