The document discusses object oriented techniques for system development. It covers key concepts like classes, objects, attributes, methods, encapsulation, inheritance, and polymorphism. It then describes the iterative development process and how it addresses limitations of the traditional waterfall model by allowing for early delivery of working software in iterations and incorporation of feedback to refine requirements and design.

1. Business Information Systems Application Development -II Object Oriented Techniques System Development Life Cycle Prithwis Mukerjee, Ph.D.

2. What shall we cover here Languages and Environments Computer Languages Development Environments Activities What are the steps required to create an application World of Objects What and why ? Business application design Software development life cycle Water fall method Iterative Method Rational Unified Process

3. Data Modelling >> Object Orientation Data Modelling ENTITY : “something” about which we store information in a structured manner Multiple “instances” of an entity exist ATTRIBUTE (s) : a set of values defined for all instances of an entity Instances of the entity have different values for the attribute C-R-U-D operations are performed on instances through Insert, Select, Update Delete in SQL Object Oriented techniques are based on the idea of .. CLASS (es) : a collection of “instances” of “something” that are similar in terms of.. 1. ATTRIBUTE (s) : a set of values defined for all instances of a class Instances of the class have different values of the attribute 2. METHOD (s) : a set of actions that affect an instance of the class Change Attribute values Create / Delete instance

4. Rigidity >> Flexibility Entity Must be reflected as TABLE in a relational database system Eg EMPLOYEE Table Instances are individual RECORDS in the TABLE One record for each employee Attribute Is reflected as a COLUMN All activity is defined in terms of insert, select, update, delete Class No common, rigid structure TABLE may be used to define classes Instances of a class are called OBJECTS Eg prithwis is an object of class EMPLOYEE Attribute No common, rigid structure prithwis . name , prithwis . age are attributes of prithwis Methods are more intuitive recruit, promote, terminate could be methods for class employee

5. Examples of Classes Physical Objects AUTOMOBILE Instances : Civic, Santro, Qualis, Attributes : Price, Horsepower, Weight Or alternatively , SANTRO Instances : my Santro, your Santro, his Santro ! Attributes : Owner, Registration Number, Colour Human entities PERSON Instances : Ram, Shyam, Madhu Attributes : Name, Gender, Age, ... Or alternatively , STUDENT Instances : Ram, Shyam, Madhu Attributes : Roll Number, Course, Grade ... Or alternatively , EMPLOYEE Attributes : Salary, Department ... INHERITANCE is the phenomenon by which one CLASS inherits ATTRIBUTES from another classes

6. More Classes ... Collections of data ORDERS Instances : Order from ITC, Tata Steel ... Attributes : Value, Quantity, Delivery Date ... BANKACCOUNT Instances : Account of Ram, Shyam, Madhu Attributes : Name, Number, PAN, balance INVENTORY Instances : Soap, Detergents, Biscuits .. Attribute : SKU, units, location, .... Elements of a Systems Environment !! WINDOWS Instances : OrderCreation, OrderModification Attributes : Size, Title, Scrollable or Not ...

7. Methods + Attributes = Classes Recollect Algorithms + Data Structures = Programs Database + Application = Systems Classes consist of Attributes Pieces of data that distinctly indentify OBJECTS ( instances ) of CLASS Methods or Functions Instructions common to a CLASS that have an impact on Attributes of an OBJECT Coded in language like C++ Class STUDENT Attribute Name Roll Number Standard Method ENROLL Create new OBJECT with Name (prithwis) Assign Roll Number Assign Standard = 1 PROMOTE Change Standard from Current Value to Current Value + 1

8. Each Class has own Attributes / Methods Class STUDENT Attributes : Name, Roll Number, Standard Methods : Enroll, Promote, Graduate Class EMPLOYEE Attributes : Name, Emp Number, Designation, Salary Methods : Hire, Promote, RaiseSalary, Fire Method A set of instructions in a language like C++ or Java that cause certain changes to happen to the attributes The same METHOD could mean different things when it applies to different CLASSes PROMOTE : STUDENT – change value of STANDARD attribute PROMOTE : EMPLOYEE – change value of DESIGNATION and SALARY POLYMORPHOSIM is the phenomenon by which the same METHOD could mean different things in different CLASSes

9. Object Oriented Techniques Deal with CLASSes which are defined as a bundle of Attributes : That is DATA Methods : That is a way of changing the DATA in a meaningful way Have OBJECTs that are instances of a CLASS with Specific values ATTRIBUTE that are Modified by “invoking” METHODs appropriate for this class Ensure integrity of data by Allowing change to happen in the values of attributes ONLY through an execution of a METHOD Consider Class EMPLOYEE Salary cannot be changed by SIMPLE SQL update to any arbitrary value Salary must change through METHOD “promote” which will ensure that salary change is as per company defined rules Encapsulation of Data and Logic in a single artefact

10. OO Application Development Model user requirement with an appropriate number of CLASSes which are defined in terms of ATTRIBUTES METHODS A Method in One class can invoke a Method in another class Method ORDER.fullfillORDER can invoke INVENTORY.reduceINVENTORY Define CLASSes along with ATTRIBUTES and METHODS using A “pure” object oriented language like C++ or Java A “hybrid” but easier-to-use alternative could be ... Visual Basic ZOHO !! A large and complex application that manages the internals of a big company can have hundreds of classes, each with its own attributes and methods. Managing all this is not easy !! We need to define a process for doing all this ...

11. OO Application Development Creates a model of a real world solution Using an object oriented language like C++ or Java In terms of a number of CLASSes A CLASS is an artefact that allows Encapsulation or bundling definition of Data in ATTRIBUTES Logic in Methods Inheritance Allows instances of one class to acquire attributes and methods from another Polymorphism Allows the same method to mean diferent things in different classes Instances or OBJECTs that are specified by values of the attributes

12. A potential violation ? Encapsulation is the process of bundling Data Attributes Are we violating the principles of keeping data and logic separate ? In a sense we are ... But not if we introduce the concept of ... Persistence When an object of a class outlives the application or method that manipulates it Consider the Similarity ENTITY in Data Model CLASS in OO Application Consider the Difference ENTITY is represented by a TABLE in an RDBMS TABLE exists in computer even when computer switched off OBJECTS along with data are lost when computer shuts down

13. Persistence CLASS A set of instructions that define ATTRIBUTES, METHODS in an OO Language Persists in computer even when it is switched off OBJECTS Created, or “instantiated” with appropriate values of ATTRIBUTE Does not persist when computer is shut off. All Data is lost. ENTITY A TABLE in an RDBMS defined in terms of COLUMNS Persists in computer even when it is switched off RECORDS Created and manipulated with appropriate SQL statements Either directly Or through a method PERSISTS in the computer even when it is shut off. No data is lost

14. Making OBJECTs persist Application Server Machine Starts Application is created Class, Attributes Defined Application Saved Application is executed Object1 created with data Object1 made persistent Application Stops Object1 destroyed with data Machine Stops Application Saved Class, Attribute Definition Saved Data with Object1 LOST Database Server Machine Starts RDBMS starts Waits for Application request ... Recieves Object1 Persists Object1 in TABLE / RECORD Waits for next request .... RDBMS stopped Machine Stops Persistent Copy of Object1 stored in Table

15. The Next Day Application Server Machine Starts Application retrieved Application Starts Object1 created with blank data Data of Object1 recovered from Persistent copy Data for Object1 modified by methods Object1 made persistent Application Stops Object1 destroyed with data Machine Stops Database Server Machine Starts RDBMS Starts Waits for Application Request ... Sends Persistent copy of Object1 ... .. Persists modified copy of Object1 .. RDBMS stops Machine Stops Modified copy of Object1 saved

16. Three Tier Architecture Application in Execution Application Not Executing Relational Database Non Relational Database OR transient objects in application persistent objects in database Commercial, “business” applications RARELY use NON RELATIONAL database CLASS definition O2 O3 O4 O1 CLASS definition User Interface

17. System Development Life Cycle Functional Specification Program Review Checklist Complexity Determination / Estimate Technical Specification Test Support Unit Test Plan Program Source Code Code Bundle / Demo Unit Test Results Support (optional) Pre-Production Support Technical Review  Client Review  Client Review Programmer Driven USER Driven Functional Design Estimate Technical Design Deliver Test Support Develop Methodology Component  Communication & Coordination (all teams)  Technical Design Walkthrough  Code Review  Client Sign Off  Legend Task With Deliverable Task Without Deliverable Optional Service Area Process Checkpoint

18. The WaterFall Method – A simplified view Analysis Design Coding Test / Deploy Users define what they want from the system Programmers re-define what they believe the users want in a more structured manner Actual program is built using an appropriate computer language like C, Java, VisualBasic Application is tested and then deployed in the end users machine

19. The WaterFall Method – Deliverables Analysis Design Coding Test / Deploy Requirements Analysis Document written in simple English language Systems Specifications written in terms of e.g. TABLES, COLUMNS, METHODS, FUNCTIONS Programs written in an appropriate language and tested individually. Unit Test Report for each program All programs tested together to ensure compatibility and consistency Integration Test Report

20. Waterfall Process Assumptions Requirements are known up front before design In reality, users do not know what they want They certainly cannot visualise what the final thing will look like Requirements rarely change They always will, however much you hate it Design can be conducted in a purely abstract space, or trial rarely leads to error The technology will all fit nicely into place when the time comes (the apocalypse)

21. Waterfall Process Limitations Big Bang Delivery Theory The proof of the concept is relegated to the very end of a long singular cycle. Before final integration, only documents have been produced. Late deployment hides many lurking risks: technological (well, I thought they would work together...) conceptual (well, I thought that's what they wanted...) personnel (took so long, half the team left) User doesn't get to see anything real until the very end, and they always hate it. System Testing doesn't get involved until later in the process.

22. What did the customer really want ?

23. An Iterative Development Process... Recognizes the reality of changing requirements Caspers Jones’s research on 8000 projects 40% of final requirements arrived after the analysis phase, after development had already begun Promotes early risk mitigation, by breaking down the system into mini-projects and focusing on the riskier elements first Allows you to “plan a little, design a little, and code a little” Encourages all participants, including testers, integrators to be involved earlier on Allows the process itself to modulate with each iteration, allowing you to correct errors sooner and put into practice lessons learned in the prior iteration Focuses on component architectures, not final big bang deployments

24. An Incremental Development Process... Allows for software to evolve, not be produced in one huge effort Allows software to improve, by giving enough time to the evolutionary process itself Forces attention on stability, for only a stable foundation can support multiple additions Allows the system (a small subset of it) to actually run much sooner than with other processes Allows interim progress to continue through the stubbing of functionality Allows for the management of risk, by exposing problems earlier on in the development process

25. Goals and Features of Each Iteration The primary goal of each iteration is to slowly chip away at the risk facing the project, namely: performance risks integration risks (different vendors, tools, etc.) conceptual risks (ferret out analysis and design flaws) Perform a “mini-waterfall” project that ends with a delivery of something tangible in code, available for scrutiny by the interested parties, which produces validation or correctives The result of a single iteration is an increment--an incremental improvement of the system, yielding an evolutionary approach