Developing Information

Systems
 Levels of Software
Hardware 1. Machine Micro logic
Logic
System 2. Supervisors or Executives
Software 3. Operating Systems
4. Language Translators
5. Utility Programs
Application 6. Word processors, spread sheets,
Software DBMS, Web servers
7. High level and assembly language
programs
End-user 8. 4GLs, SQL
Software
Program Vs. Software Product
• Program • Software Product
• Personal use – Multiple developer
• Limited life – Multiple user
• No need for a good
interface – Longer Life span
• No need for – Thorough testing and
documentation careful implementation
• ……. – Good user interface,
user manual
– Maintainable - Good
documentation support
Changes in software development style
• Early computer programming
• Slow Computers, small programs, assembly level programming
• Exploratory programming style
• High-level language programming
• Semiconductor technology and compilers
• High level languages like COBOL, FORTRAN, ALGOL
• Control flow-based design
• Stress on control structures
• The sequence of program instructions
• Flow charting technique
• Structured programming methodology
• Avoidance of goto
• Single entry – single exit structures
• Sequence, selection and iteration
• PASCAL, MODULA, C
Changes in software development style
(Contd.)
• Data structure-oriented design
• More importance to data structure
• Jackson’s structured programming, Warnier-Orr methodology
• Data flow-oriented design
• Complex software products
• Data flow oriented techniques
• Identification of major data items
• Flow of data between the processes
• Object-oriented design
• Objects
• Relationship among the object
 Software Process Models
• Code and fix model
• Classical waterfall model
• Evolutionary model
• Prototyping
• Spiral models
• …
• …
Classical Waterfall Model
Feasibility
Study

Requirements
Analysis

Design and
Specification

Coding and
unit testing

Integration and
system testing

Maintenance
Feasibility study
• Abstract definition of the problem
• Formulation of alternative strategies
• Systems Engineering
• Examination of alternatives
• Resources required and available
• Development cost and time
• Cost-benefit analysis
Requirement Analysis
• Requirement Analysis
• Interviews and discussions
• Incomplete views
• Ambiguities and contradictions
• Requirements Specification
• User manual
• System test plan
• End product - SRS Document
Design
• Translation of SRS into a structure that is suitable for implementation
• Traditional design approach
• Structured Analysis – DFD
• Architectural design
• Detailed design
• Object oriented design
• Identification of objects and relationships
• Detailed design
• End product – A set of design documents
Coding and Unit Testing
• Translation of designs to source code
• Testing each program module
• End product – a set of program modules that are individually tested.
Integration and Unit Testing
• Partial integration and testing
• System testing
• Alpha testing
• Beta testing
• Acceptance testing
Maintenance
• Corrective
• Perfective
• Adaptive
Usefulness of the waterfall model
• Complete specification of the system before it is built
• Understanding interaction of the components before coding
• More accurate tracking of the project and early discovery of the
schedule slippage
• Documentation for ease of testing and maintenance
• Reduced development and maintenance cost
• More structured and manageable system.
Shortfalls of Waterfall Model
• Protracted Integration and Late Design Breakage
• Blocking state of developers
• Working version takes long time to come up
• Non-optimal-fixes, little time for redesign, late delivery of a non-
maintainable product
• Late Risk Resolution
• Risk: the probability of missing cost, schedule, feature, or quality goal
• High at the requirement phase
• Requirement driven Functional decomposition
• customers must state all requirements explicitly
• All the requirements are equally important and do not change over the
SDLC
• Decomposition of requirements to functions and sub functions
• Adversarial stakeholder relationship

As a result
Real projects rarely follow this model
The Incremental model
• Applying linear sequence in a staggering manner
• First increment is the core product
• Focuses on the delivery of an operational product
• Useful when staffing is inadequate
• Technical risk can be handled
The Incremental model Communication

Planning

Modeling
Software Functionality and Features

Construction

Deployment

Calendar Time
The RAD Model
(Rapid application development)

• Fully functional system in a short time

(60 –90 days)
• Phases
• Communication
• Planning (for multiple teams)
• Modeling (Business, Data, Process)
• Construction (Use of Components, Automatic Code generation)
• Deployment (Integration, Delivery, Feedback)
The RAD Model contd.
Team #1

Communication
Modeling
• Shortfalls
• Sufficient and efficient manpower Construction

• Commitment of the team Team #2

Modeling
members
• Appropriate modularization Construction
• Not suitable for high technical risk Team #n

projects Modeling

Construction
 Component Based Models
-Software Reuse
Requirements Detail Design of the
Remaining
Components
Design of Architecture
Coding and Unit of the
Remaining
Components
Component
Specification

Search for reusable

Integration
components

Delivery
Advantages of Software Reuse
• Increases system reliability
• Reduces overall project risk due to less uncertainty in cost estimates
• Effective use of specialists in developing generic components than in
a wide array of variety of products
• Embodiment of organizational standards in reusable components,
such as user interface and error handling procedures
• Reduction of software development time.
Common Problems of
Software Reuse
• Portability
• Transportation
• Adaptation
• Customization
The Prototyping Model
• Iterative in nature
• Customers are unsure of Communication
their requirement
• Developers are unsure of the Quick Plan
development environment Deployment,
• Can be applied with any delivery and
other paradigm feedback
Modeling and
• Evolutionary or throwaway quick design
Construction of
the Prototype
Evolutionary Vs. Throwaway Prototyping
• Both types assume that at the outset some abstract, incomplete set of
requirements has been specified.
• Both allows user feedback
• Evolutionary prototype is delivered to the customer with minimal changes.
• Throwaway prototype is used just to collect user requirements. Hence the actual
deliverable is developed afterwards.
• Evolutionary prototype is difficult to maintain
• Throwaway prototype is not suitable for testing non-functional requirements
Benefits of Prototyping
• Resolves communication gap and misunderstanding between
software developer and users.
• Missing user services may be detected
• Difficult to use or confusing user services may be identified and
refined
• Resolves inconsistencies and incompleteness in the users’
requirements
• Helps in gaining user confidence
• Helps in writing specifications
• Correct specifications of the requirements reduces requirements-
related errors and therefore overall development cost
• Training user before delivering the product
• Test cases developed during prototyping can be used for testing the
final product.
Guidelines for developing the prototype

• Objective of the prototype must be explicitly stated to

the user
• Validate functional requirement
• Validate user interfaces
• Requires cost
• Non-functional features can be ignored
• Need not maintain error handling routines
• Need not adhere to the quality and reliability standard
• Suitable tools or development languages may be used
• Usable components
• Executable specification language – z specification language
• Forth generation language – SQL
• Very high-level language – Smalltalk, Prolog or Lisp
Shortfalls of Prototyping

• Customers wishes to have it as the working product

• Developers makes compromises to make it the working product
Requirements Analysis
Analysis Models
• Elaborating and understanding requirements
• Structured Analysis
• Object Oriented Analysis
Structured Analysis
• Derived from the ideas of structured programming
• Tools
• Data flow diagrams
• Data dictionaries
• Structured English
Data Flow Diagrams
• A graphical technique to understand the data flow,
data transformation and data stores in an information
system
or

A Data Store
A Data Flow or

A Process or Data
Transformation
An External Entity
DFD for a Customer Order Receipt

Customer Order
File

Verified Order
Customer Order
Customer Clerk
Verifies
Acknowledgement
Order
Hierarchical Organization of DFD
• Context Level Diagram
• Identifies external entities, major data flow across the
boundary separating system from external entities, and
thus defines the context in which the system operates.
• Normally has only one process bearing the name of the
task done by the system.
• Overview Diagram (Level-Zero/ Zero-Level Diagram)
• Explosion of the context level DFD
• Gives overview of the major functions of the system
• Shows major data stores used in the system
• Exploded Bottom-Level Diagram
• Depending on the need a higher level DFD can explode to
many lower level one.
 Area of
Investigation

More details of the area of investigation

More details for a lower level area

Still more details for one second level area

 An Accounts Payable System
National Merchandise receives invoices from its vendors by mail.
Every morning the mail room manager, Ross Manning, delivers all
invoices and all mail addressed to the accounts payable department
to Ginny Anderson, the accounts payable clerk, who accumulates
invoices throughout the week in an accordion folder. On Thursday,
she reviews them and adds amount due and invoice number to the
vendor ledger card – a manual record of all accounting transactions
for the particular vendor. The invoices themselves are stored
alphabetically in a filing cabinet.
 cheques for payments to vendors are written and signed each
Friday. Harry Demming, manager of the accounts payable
department, reviews all accounts and outstanding invoices, and
determines which ones should be paid. He writes the cheque and at
the same time enters the amount of the cheque, name of the
vendor and the number of invoices paid in the chequebook. The
same information is entered on the ledger card of the vendor.

The cheques are sent in one batch, with appropriate invoices, to the
controller Ann Williams, who reviews and signs each cheque. In
some cases, she disapproves the payment and returns the cheques
back to Harry unsigned.
 Context-Level DFD of an
Accounts Payable System

Accounts
payable
Payable Balance

Vendor
Invoice
Mailing Address
Accounts
Vendor
Payable
cheque

Vendor Data
 Overview Diagram
(Zero-Level DFD)
Purchase Orders Vendor accounts Accounts Payable
Vendor Data
Purchase Orders Mailing
Account Balance Payable Balance Address
Details

Vendor Accounts 3.0

2.0
Invoice 1.0 Due cheque
Revised Write
Invoice
Balance Vendor
Approval
Due cheques
Vendor Vendor
Payment Batched
Voucher Invoice

Payable Invoice cheque Account Balance

Amount

chequeing
Accounts
 Process Hierarchy Chart
A/Cs
Payable

Approve Revise Write

Invoice balance cheques
due

Verify Revise Log Log Approve

Verify
Purchase Vendor account cheques cheques
Price
Paymt info Payable
info

Accept Prepare Prepare

Verify …. Invoice vendor cheque
invoice
payment approval
summary
 Purchase
Order
Purchase Order
Details
Signed
Invoice 1.3
Invoice 1.1 Verify 1.5
Verify Signed merchandise Price Invoice
Invoice ordered Invoice
Invoice Package Pricing
Details Details
Unsigned Invoice Log
Received Approved
Invoice Invoices Unverified Invoices
Invoice Audited Accepta
Signed Invoice nce
Invoice
Invoice Package Details
1.2 1.4
Verify Receive 1.6
acceptance of purchase Accept Invoice
merchandise authorization
Payment
vouchers

Payable
Invoices
Data Dictionary – The Data about the Data (Meta
data)
Serves multiple purposes

• Documents the details about the system components

• Data flows, data stores, and processes.
• Gives meaning to each system component.
• Helps identifying errors omissions in the system.
Standards Maintained while Recording Data
Defining data flows Defining data stores
Data flow name Data store name
Description Description
From Processes Inbound data flows
To Processes Outbound data flows
Data structure Data structure
Volume
Access

Defining processes
Process name
Description
Input
Output
Logic summary
Structured English
• Natural English written in a structured programming fashion
• Sequence
• Selection
• Iteration
Guidelines for Writing Process logic in
Structured English
• Mostly imperative statements
• Do not use unclear verbs (operate or handle)
• Do not use adjectives without precise meaning (Some /
few)
• Data flows in lower case letters within quote
• Data Store names in capital letters
• Arithmetic and Boolean symbols can be used
• Keyword in capital letter (ex. DO, WHILE, IF …)
• Keywords BEGIN and END to represent logic blocks
(Sequence)
• IF-THEN-ELSE : Selection
• WHILE-DO, REPEAT-UNTIL, FOR repetition
Advantages of Using
Structured English
• Easily understood by the manager
• Can be used to explain the procedures and decision situations in problem
domain
• Easily understood by the developers
• Easily converted to program codes in solution domain
Introduction to Software Design
Design is Important
• It provides the basic framework in which the program code are
to be written and personnel are to be assigned to the work.
• Design error outweigh coding errors; i.e., they are more in
number than the coding error.
• They take more time to detect and correct than the coding.
• Compared to coding they are costlier to correct.
• They provide a basis for monitoring the progress.
• Good design helps in creating reliable, flexible and
maintainable software.
• The larger the system and the larger the number of developers
involved, the more important the design becomes
Design and Coding Errors
(Boehm et al., based on a study of 220 errors)

Design Errors Coding Errors

Total 64% 36%

Average 3.1 hours 2.2 hours

Diagnostic Time
Average 4 hours 0.8 hours
Correction Time
Design Consists of
• Program Design
• Structured Design
• Object Oriented Design
• Database Design
• User Interface Design
Basic Principles of Program Design
• Abstraction
• Divide and conquer concepts
• Control Hierarchy
• Principle of Information Hiding
• Principle of Localization
Abstraction
• The process of forming a general concept as separate
from the particular instance.
• Levels of Design
• The architectural design
• High level : only general structure
• Decomposition into subsystems with interfaces
• Verification against the software specification
• Architectural review and design baseline
• The detailed design
• Allocation of requirements to modules
• Specific algorithms and data structures for each module (subsystem)
• Verification against requirements and baselined architectural design
• Baselining the detailed design
Divide and Conquer
• Dividing a problem to smaller and independent sub-problems.
• Functional decomposition
• Module interfaces
• Parameter passing
• Protocol governing the communication between the modules
Control Hierarchy
• Control flow among the modules
• The idea behind structured design
Information Hiding
• Independent modules communicating only for that information that
is necessary for the software function
• Advantages
• Ease of coding
• Ease of Testing
• Avoidance of error propagation
• Multilevel functional decomposition
• Stepwise refinement: The process of hierarchical decomposition
• Modularity
• Module: The basic unit of in software architecture
Principles of Localization
• All logically related items should be placed physically close to one
another
• Principle applies to both data sets and the program sets.
Top-down design
• Stepwise refinement
• Most general to special sub-functions
• Guidelines
• While breaking components into parts, the components within each part
should be logically related
• Alternative designs are considered
• As little decision as possible at each step.
Principles of Top-Down Design
• Specification of input, process, and output for each module at each
design step
• Implementation issues are not addressed till late in design process
• Brief description for each module
• Careful specification of interfaces
Structured Design
Concepts
• Follows the tradition of structured programming, hence the name
• A refinement of top-down approach with the principle of modularity
at its core
• Structured Charts – the diagrammatic tool used for structured design
 Structured Charts
• A graphic representation of the program structure in the form
of a hierarchy of modules.
• It normally has more than one hierarchy

A module
Produce Sales
Summary Module Invocation
Region Sales
Data transfer
Sales
Region
Control info transfer

Read Sales Print Sales

Transactions Summary
Structured Charts
• Normally does not show the important program structure.
• Sometimes the following rules are used
• Sub modules are used sequentially from left to write
• Selections and iterations are represented as shown below

A A

B C B C

Selection Iteration
Basic principles of modular design
• Functional independence of the modules
• Abstraction
• Information Hiding
• Advantages
• Ease of development
• Ease of Testing
• Ease of maintenance
• Module independence is measured using two
qualitative criteria
• Coupling between modules
• Unrelated parts of a program should reside on different modules.
• Cohesion within the module
• Highly inter-related parts of a program should reside within a
module
Object Oriented Concepts
Operations and Data
• All programming languages perform operations on data

• Example 1: Banking information system

• Data: accountBalance
• Operations:
deposit
withdraw
• Example 2: Hospital information system
• Data: patientName
patientDateOfBirth
patientGender
• Operations:
admitPatient
dischargePatient updatePatientMedicalRecord
What is Object Orientation?

• Procedural paradigm:
• Software is organized around the notion of procedures
• Procedural abstraction
• Works as long as the data is simple
• Adding data abstractions
• Groups together the pieces of data that describe some entity
• Helps reduce the system’s complexity.
• Such as Records and structures
• Object oriented paradigm:
• Organizing procedural abstractions in the context of data abstractions
Object Oriented paradigm
• An approach to the solution of problems in which all computations
are performed in the context of objects.
• The objects are instances of classes, which:
• are data abstractions
• contain procedural abstractions that operation on the objects
• A running program can be seen as a collection of objects collaborating
to perform a given task
A View of the Two paradigms
A data structure for stack in a procedural Language
Variables:
a[1..n]: array of integers, top: integer
No mechanism to put
Functions: variables with
Stack_Push(element:integer) functions together
Stack_Pop() // returns the top element
Stack_Is_Empty() // returns true/false

Stack as a class
Attribute:
a[1..n]: array of integers, top: integer
Methods: A mechanism to put
Stack_Push(element:integer) variables with
Stack_Pop() // returns the top element methods together
Stack_Is_Empty() // returns true/false
A View of the Two paradigms
Defining an Object
• An object is anything, real or abstract, which is
characterized by the state it occupies and by the activities
defined on that object that can bring about changes in the
state.
• Major Concepts
• Abstraction
• Encapsulation
• State Retention
• Information hiding
• Object identity
• Message Passing
• Classes
• Inheritance
• Polymorphism
ABSTRACTION
• "An abstraction denotes the essential characteristics of
an object that distinguish it from all other kinds of
objects and thus provide crisply defined conceptual
boundaries, relative to the perspective of the viewer”
• Refers to the act of representing essential features
without including the background details or
explanations.
Encapsulation
• Behaviour and information are encapsulated in
objects
• Encapsulation is the process of compartmentalizing
the elements of an abstraction that constitute its
structure and behaviour
• Only the 'interface' of an object is 'visible' to other objects
• Other objects only know operations on an object, not how
they work nor about other characteristics
• Necessary prerequisite for information hiding
Information Hiding
• Information hiding enhances maintainability
• Implementation details are invisible outside an object

• Example: Bank Account Class

• Attribute accountBalance can be implemented in many different ways:
• As an integer (the total amount in cents); or
• As a dollar amount with two decimal places for the cents
• With information hiding, these details are invisible

• Advantages
• Localized design decision
• Decoupling of information from its form

• With information hiding

• A system consists of essentially independent objects
• They communicate by sending messages
Messages
• Objects communicate by passing messages
• Customer.AddPayment(cashRendered)
• Can be of three types
• Informative
• Employee.UpdateAddress(Address)
• Interrogative
• Inventory.getStatus
• Imperative
• Payment.computeAmount(quanity, price)
Classes
• Classes represent groups of objects which have the same behaviour and
information structures.

• A class represents a template for several objects

• Objects of the same class have the same definition both for their operations and
for their information structure
Object Identity
• Every object is an instance of a class
• A class defines the possible behaviors and the information structure of all its
object instances.
• Different instances may have their operations activated in different ways and
in different sequences ; hence they may be in different states.
Object Identity
A chunk of structured data in a running software system
• Has properties
• Represent its state
• Has behaviour
• How it acts and reacts
• May simulate the behaviour of an object in the real
world
Inheritance
• Inheritance is a relationship between different classes which share
common characteristics.
• “If class B inherits class A, then both the operations and information
structure in class A will become part of class B” (Jacobsen 1992)
• Major benefits are simpler, clearer classes, at higher levels of
abstraction
Generalization & Specialization

• Generalization
• Creation of an 'ancestor'
• Specialization
• Creation of a 'descendant'
Multiple Inheritance
• 1 class inherits from 2 or
more existing classes
• Allows more complex
class structures, but less
easily understood
Ambiguities through Multiple Inheritance
Relationships between Classes
• Inheritance is an implementation of the generalization relationship

• Other possible relationships between classes include

• Aggregation
• Association
Aggregation and Association
• The aggregation relationship is appropriate when class
X “consists of” classes Y and Z
• Example: A car is constructed from a chassis, engine, wheels,
and seats
• Association is an arbitrary relationship between two
classes
• Example: A radiologist may consult a lawyer regarding the
interpretation of a contract
Polymorphism
• A property of object oriented software by which an abstract operation
may be performed in different ways in different classes.
• Requires that there be multiple methods of the same name
• The choice of which one to execute depends on the object that is in a variable
• Reduces the need for programmers to code many if-else or switch statements
• Method Overriding
• An overrided method redefines an existing method in a superclass to specify a
new behavior.
• Method Overloading
• Overloading means that you have multiple methods with the same name but
with a different parameter list.
• Dynamic Binding
• The code associated with a given procedure is not known until the time of the
call at run time.
 Polygon
Area
getArea

Triangle Rectangle Hexagone

getArea getArea getArea

Ex. Method Overriding

Refreshing OOP Terminology

• Class: A user-defined prototype for an object that defines a set of attributes that characterize
any object of the class. The attributes are data members
It’s a template to create object.
A way to create User defined data type to be able to represent real world object and hence
solve real word problem.
• Class variable: A variable that is shared by all instances of a class. Class variables are
defined within a class but outside any of the class's methods. Class variables are not used as
frequently as instance variables are.
• Inheritance: The transfer of the characteristics of a class to other class. Facilitates Code
Reusability and feature enhancement.
• Data member: A class variable or instance variable that holds data associated with a class
and its objects.Classes that are derived from it.
Overview of OOP Terminology (Contd..)
• Instance: An individual object of a certain class. An object obj that
belongs to a class Circle, for example, is an instance of the class Circle.
• Instance variable: A variable that is defined inside a method
and belongs only to the current instance of a class.
• Instantiation: The creation of an instance of a class.
• Method : A special kind of function that is defined in a class
definition.
• Encapsulation : Dividing the code into a public interface, and a
private implementation of that interface
UML: A tool for object oriented
analysis and design
What is UML?
• The Unified Modelling Language is a standard graphical
language for modelling object oriented software
• At the end of the 1980s and the beginning of 1990s, the first object-
oriented development processes appeared
• The proliferation of methods and notations tended to cause
considerable confusion
• Two important methodologists Rumbaugh and Booch decided to
merge their approaches in 1994.
• They worked together at the Rational Software Corporation
• In 1995, another methodologist, Jacobson, joined the team. His work
focused on use cases
• In 1997 the Object Management Group (OMG) started the process of
UML standardization
Types of Diagrams
• Class diagrams
• Object diagrams
• Use case diagrams
• Sequence diagrams
• Collaboration diagrams
• Statechart Diagrams
• Activity Diagrams
• Component diagrams
• Deployment diagrams
Use case diagrams
• Use case diagrams describe what a system does from
the standpoint of an external observer. The emphasis
is on what a system does rather than how.
• Use case diagrams are closely connected to scenarios.
A scenario is an example of what happens when
someone interacts with the system.
• A use case is a summary of scenarios for a single task
or goal. An actor is who or what initiates the events
involved in that task. Actors are simply roles that
people or objects play.
 a scenario for a medical clinic
"A patient calls the clinic to make an appointment for a
yearly checkup. The receptionist finds the nearest empty
time slot in the appointment book and schedules the
appointment for that time slot. "

Use case diagrams are helpful in three areas.

•determining features (requirements).
•communicating with clients.
•generating test cases
Use case for a Medical clinic
Class diagrams
• A Class diagram gives an overview of a system by
showing its classes and the relationships among
them.
• Class diagrams are static -- they display what interacts
but not what happens when they do interact.
• Symbolic Notations
• Class
• Relationships
• Dependency
• Generalization
• Association
• Aggregation
Class

Class Name

Attribute

Operations

Relationships
Dependency

Message
:B :C

Dependency:
Change in C will
:A affect A
Generalization
 Association
Adornaments: Name, Role, Multiplicity

Multiplicity
Direction
Name

Trains 1..*
Trainer 1 Trainee
Teacher Student
(Role) (Role)
Aggregation, Composition

Composition Aggregation
Whole-part relationship
class diagram for a
customer order
from a retail
catalog
A Package
Diagram
Interaction Diagrams
• An interaction is a behavior that comprises a set of
messages exchanged among a set of objects within a
context to accomplish a purpose.
• Sequence Diagram
• Emphasizes on the time ordering of the message
• Collaboration Diagram
• Emphasizes on the structural organization of the objects
that send and receive messages
Sequence Diagram
Reserving a hotel room
Collaboration Diagram
Reserving a hotel room
Activity Diagrams
• Interaction diagrams show the flow of control from
object to object where as activity diagrams show flow
of control from activity to activity.
• Activities result into some action that that is made up
of atomic computations, that result in a change in
state of the system.
• Actions encompass calling another operation, sending
a signal, creating or destroying an object, or some
pure computation.
Activity Diagrams
• States:
• Start State
• End State
• Action state
• Activity state
• Transition
• Directed arrows
• Branching
• Guard expression
• Forking and joining
• Swimlanes
• Object flow
Statechart diagrams
• A statechart diagram shows the possible states of the object and the
transitions that cause a change in state.
• While a statechart diagram focuses attention on an object undergoing
a process (or on a process as an object), an activity diagram focuses
on the flow of activities involved in a single process.
Login part of an online
banking system
UML Tutorials
• http://www.smartdraw.com/tutorials/software-uml/uml.htm
• http://www.cs.toronto.edu/~jm/340S/lectures.html
• http://www.math-cs.gordon.edu/courses/cs211/ATMExample/Intro.html