• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
BIS08 Application Development - II
 

BIS08 Application Development - II

on

  • 1,397 views

Course Material for MBA Course on Business Information Systems

Course Material for MBA Course on Business Information Systems

Statistics

Views

Total Views
1,397
Views on SlideShare
1,396
Embed Views
1

Actions

Likes
1
Downloads
95
Comments
0

1 Embed 1

https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    BIS08 Application Development - II BIS08 Application Development - II Presentation Transcript

    • Business Information Systems Application Development -II Object Oriented Techniques System Development Life Cycle Prithwis Mukerjee, Ph.D.
    • 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
    • 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
    • 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
    • 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
    • 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 ...
    • 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
    • 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
    • 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
    • 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 ...
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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)
    • 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.
    • What did the customer really want ?
    • 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
    • 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
    • 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