1
Unit-1
INTRODUCTION SYLLABUS: Categories of Information systems-traditional paradigm vs. Object oriented paradigm-Objects and
Classes-Inheritance-Object relationship-Examples of UML class modeling-Unified Process-
Iteration and incrementation within the unified process. INTRODUCTION :
Object-oriented analysis and design (OOAD) is a software engineering approach that
models a system as a group of interacting objects. Each object represents some entity of
interest in the system being modeled, and is characterized by its class, its state (data elements)
and its behavior. Various models can be created to show the static structure, dynamic behavior,
and run-time deployment of these collaborating objects. There are a number of different notations
for representing these models, such as the Unified Modeling Language (UML).
Benefits
Easy to understand Maintainability Data re-use
1.1 CATEGORIES OF INFORMATION SYSTEMS
A system is a set of artifacts (components) that together achieve some outcome. An
information system is a system that achieves a business outcome. It collects, manipulates, stores
and reports information regarding the business activities of an organization in managing the
operations of the business.
The two major categories of computerized Information systems are
Custom information Systems
Commercial off-the-shelf (COTS) packages
2
Custom Information System (CIS) is an information system that has been developed for one
specific client. For example, the information system developed for Jethro’s Boot Emporium is a
custom Information System- the boot fashion trend detection component is used by no other
company. The 3 main stakeholders when a Custom Information System is developed are
The Client, who is paying for the Information System to be developed The future Users of the Information system. The developers of that information system
The task of the developers is to determine the needs of the client and to develop an information
system that satisfies those needs and can effectively be utilized by the users. Another example of
a custom information system is a management information system for a major car rental
company.
Disadvantage: Custom Information Systems are expensive and an organization might be
tempted to recoup some of the cost by selling a copy of its custom information system to its
competitor. For this reason, the resale market for this system is small. CIS incorporates the
business model of organization that commissioned it and selling a copy of such a CIS means
giving away proprietary information to a competitor.
Commercial-Off-The-Shelf (COTS) is also called Shrinkware, because the diskettes or CDs on
which the package used to be supplied were placed in a box together with the manual and the
box was then shrink-wrapped. Nowadays, however, COTS packages are frequently downloaded
over the Internet- called as Clickware. There are only two major stakeholders for a COTS
package:
The Developers
The Users COTS packages are intended to provide functionality that will satisfy the needs of as large a user
base as possible. Some COTS are relatively small and cheap and are intended to satisfy the
information system needs of smaller businesses. COTS packages include TurboTax, Microsoft
Excel and Peachtree Accounting System.
3
In contrast, an Enterprise Resource Planning (ERP) system such as PeopleSoft or SAP is a huge
package intended to provide almost all the information needs of a large corporation,
including accounting, payroll, inventory, sales, purchasing and personnel and so on. Thus COTS
packages like ERP systems lie between the pure CIS and COTS packages that are unchangeable.
1.2 TRADITIONAL INFORMATION SYSTEM DEVELOPMENT
The information system life cycle is the way that an information system is constructed, as it is
almost always easier to perform a sequence of smaller tasks than one large task, the overall life
cycle is broken into a series of smaller steps called phases. The number of phases varies from
organization to organization. Typically there are six phases Requirements phase
In this phase, the client’s requirements are extracted. The client and the future users of
the information system to be developed interact with the information system development team
in order to determine the client’s needs. The results of this study are presented in the form of a
requirements document. The requirements document is only a few pages long, with the specific
needs listed as bullet items. Analysis Phase
The aim is to draw up the specification document. The specification document lays out
what the information system has to do. If the delivered information system satisfies the
specifications, then the client pays the developers for the information system. If not the
developers have to fix the information system until it satisfies the specifications. The
specifications describe what the system has to be able to do. Once the specification document has
been signed off by the client, the project management plan can be drawn. This detailed plan
includes a budget, staffing needs and a list of what will be delivered to the client and when it will
be delivered. Design Phase
In this the members of the development team describe how the information system is
developed. Typically the system is broken into smaller pieces called modules.
4
Each module is designed in detail; the development team has to describe the algorithms
used by the module (how the module performs the task) and data structures within the modules
(data on which the module is to operate). The result is represented in the form of a design
document.
Implementation phase
The design of the modules is given to the design team to translate into an appropriate
programming language. COBOL is the world’s most widely used programming language,
whereas the modern information systems are often implemented in C++ or Java. Modules are
integrated (combined) to form the complete information system.
Maintenance phase
After the information system has been installed, it will need to be modified either to
remove any remaining faults from the system or because the system needs to be extended in
some way. Retirement
Finally after 10 or 15 years of maintenance, an information system is retired if it is no
longer performs a useful service.
There is no planning phase
o Beginning of the project-preliminary planning takes place to manage the requirements
and analysis phases
o To draw management plan-budget, staffing requirements and detailed schedule
o Project management need to monitor the project management plan and be on the watch
for any derivation from the plan. There is no planning phase instead; planning activities are carried out all through the life cycle.
There is no testing phase
o Validation and verification is missing
5
There is no documentation
o It is necessary to update each information of the system development. It is necessary when
the developer changes, as the document designing will be tedious.
o Essential for back reference in case of troubleshooting.
o Necessary for testing a new client’s requirement.
o Maintenance is impossible if there is no documentation 1.3 Traditional Paradigm Vs Object-Oriented Paradigm
The computer age started in the 1940s, so Information Systems (IS) are hardly more than
50 years old. Developing IS was initially considered a creative skill; individuality was highly
prized. However, as larger computers became more affordable, it became possible to run an
information system that was too big to be developed by just one person, if that information
system was to be completed by the deadline specified by the client. Instead, IS began to be
developed by teams. Furthermore skill specialization became the industry norm. Instead of
information technology professionals being involved in all the phases- 2 separate professions
arose: System analysts to perform the requirements, analysis and design phases and
Programmers to do the implementation.
The first systematic approach to information is called the Traditional paradigm
/methodology or Structured methodology /paradigm. Initially this method was extremely
successful. This was treated as methodical discipline rather than a creative activity. The quality
of Information system improved and the delivery of the IS on time and within the budget started
to become a realistic expectation.
During the 1980s, the cost of hardware continued to decrease fast. As larger computers
became more affordable, the size of IS continued to grow. But larger the IS, the less successful
the traditional paradigm proved to be. Finally, the IS community realized that the traditional
paradigm had outlined its usefulness and something more was needed.
6
Traditional method went well with small scale IS (approx. 5000 lines of code), but not
with medium scale IS (approx. 50000 lines of code) and long scale IS (approx. 5000000 lines of
code). This method ignored the data in favor of the operations.
In contrast, the Object-Oriented Paradigm pays equal attention to operations and data.
The Standish Group is a research firm that analyses the development of IS. Their study of
280000 development projects completed in 2000 and is summarized as
The financial and legal implications of unsuccessful projects are horrendous. A survey conducted
by the Cutter Consortium revealed that an astounding 78 percent of the information technology
organizations surveyed have been involved in disputes that ended up in litigation
In 67% of the disputes, the functionality or performance of the information system as
delivered did not meet up to the claims of the developers
In 56% of the disputes, the promised delivery date slipped several times
In 45% of the disputes, the defects were so severe that the information system was
unusable. These reasons forced organizations to change to the object-oriented paradigm.
1.4 OBJECTS & CLASSES
A class is a set of objects that share a common structure (instance variables) and behavior
(methods) and the inheritance for objects. The chief role of a class is to define the
properties and procedures (state and behavior) and applicability of its instances.
7
Each object is an instance of a class. Objects perform operation in response to messages.
e.g. when brake pedal is pressed, message is passed to the vehicle for it to stop
A method implements the behavior of an object. It is a function or procedure that is
defined for a class and typically can access the internal state of an object of that class
to perform some operation.
Behavior denotes the collection of methods that abstractly describes what an object
is capable of doing. Each procedure defines and describes a particular behavior of an
object.
1.5 INHERITANCE
Inheritance is the property of object-oriented systems that allows objects to be built from
other objects. Inheritance is a relationship between classes where one class is the parent class of
another (derived) class. The parent class is known as base class or super class. The child class is
known as derived class or sub-class. Sub-class inherits all of the properties and methods defined
in Super class. Sub-classes generally add new methods and properties specific to that class.
Thus inheritance allows classes to share and reuse behaviors and attributes. It is a top-down
relationship.
8
The Bank Account Class is a class and the Current Account Class is a subclass of Bank Account
Class. The open triangle below Bank Account Class tells that Current Account Class has all the
features of Bank Account Class (derived part) but in addition has features of its own that are
specific to Current Account Class (incremental part) such as Calculate interest. The different
ways of describing the relationship are
1) Current Account class is a subclass of Bank Account Class
2) Bank Account Class is a super class of Current Account Class
3) Current Account class is a specialization of Bank Account Class
4) Bank Account Class is a generalization of Current Account Class
5) Current Account class is a Bank Account Class
6) Bank Account Class is the base class; Current Account Class is the derived class
7) Bank Account Class is the parent class; Current Account Class is the child class Therefore Current Account class inherits from Bank Account Class
These ideas can be extended to Savings Account Class as well. Thus both Current Account Class
and Savings Account Class inherit all the features from Bank Account Class along with its own
features.
Types of Inheritance :
1) Single Inheritance: Derivation of class from only one base class is called single inheritance.
2) Multiple Inheritance:Derivation of class from several base class is called multiple
inheritance.
9
3) Hierarchical Inheritance: Derivation of several classes from a single class is
called hierarchical inheritance.
4) Multilevel Inheritance: Derivation of a class from another derived class is called multiple
inheritance.
5) Hybrid Inheritance: Derivation of a class involving more than one form of inheritance
is called hybrid inheritance.
1.6 OBJECT RELATIONSHIPS
GENERALIZATION
Generalization is a mechanism for combining similar classes of objects into a single
general class. It identifies commonalities among a set of entities. The commonality may be
attributes, behavior or both. Inheritance can be equalized to inheritance. Inheritance is
programming implementation of generalization. Generalization is a bottom-up process.
SPECIALIZATION
It is an ability of an object to inherit operations and attributes from the super class or base
class with possible restrictions and additions.
Figure : Generalization & Specialization
AGGREGATION
Aggregation represents a relation “contains”, “is a part of” and “whole- part” relation. It is
indicated by a line adorned on the “whole” by a hollow diamond along with name of
relationship and cardinality. Example: a Library contains Books (one-to-many)
10
Figure: Aggregation
ASSOCIATION
An association is a connection between classes, a semantic connection between objects of classes
involved in the association. Association typically represents “has a” or “uses” relationships. It is
indicated by a line, sometimes with arrow indicating unidirectional relationship, adorned by the
name of the relation, and the ends of the line adorned by cardinality of relationship and
optionally by the roles connected to each class. It is also known as Client-Server
association or Consumer-Producer association.
Figure : Association POLYMORPHISM
The word “poly‟ means many and “morph‟ meaning form. It is the ability of same operation to
apply to different classes. Basically the ability to define a method in a class and to have
that method exists for all subclasses of that class even when the subclasses a very different in
their behavior. It allows writing generic, reusable code more easily because we can specify
general instruction and delegate the implementation details to the objects evolved.
11
1.7 UNIFIED MODELING LANGUAGE
System is any process or structure. Example: Organizational structure of Corporation-Health
Services, National economy
Model is an abstract representation of a system, constructed to understand the system prior
to building or modifying it. Two types of models are
Static- it is a snapshot of system parameters at specific point of time. E.g. UML diagrams
Dynamic- it is viewed as a collection of procedures or behaviors taken together of a
system over time. The relationships show how the business objects interact to perform tasks.
Modeling
Building a model for a software system prior to its construction is an essential as having a
blueprint for building a large building. Rigorous modeling is essential. It must include
Model elements- which form the fundamental modeling concepts and
semantics.
Notation- visual rendering of model elements
Guidelines- expression of usage within the trade
12
Benefits
Clarity
Familiarity
Maintenance
Simplification Advantages
Models make it easier to express complex ideas
Reduction of complexity by separating the unimportant aspects from those are important
Models enhance and reinforce learning and training
Cost of the modeling analysis is much lower than the cost of similar presentation
conducted with a real system. UML
The unified modeling language (UML) is a language for specifying, constructing, visualizing and
documenting the software system and its components. The UML is a graphical language with
sets of rules and semantics.
The primary goals in the design of the UML are
Provide users a ready-to-use, expressive visual modeling language so they can develop
and exchange meaningful models
Provide extensibility and specialization mechanisms to extend the core concepts.
Be independent of particular programming languages and development processes. Provide
a formal basis for understanding the modeling language.
Encourage the growth of the OO tools market. Support higher-level development concepts.
Integrate best practices and methodologies UML has 9 graphical diagrams
o Class diagram(static) o Use-case diagram(static) o Behavior diagram(dynamic)
13
o Interaction diagram o Sequence diagram o Collaboration diagram
o State chart diagram o Activity diagram o Implementation diagram. o Component diagram o Deployment diagram.
Static Diagrams:
1. CLASS DIAGRAMS
Class diagrams are the backbone of almost every object-oriented method including UML. They
describe the static structure of a system. Classes represent an abstraction of entities with common
characteristics. Associations represent the relationships between classes. Symbols & Notations
Illustrate classes with rectangles divided into compartments. Place the name of the class in the
first partition (centered, bolded, and capitalized), list the attributes in the second partition, and
write operations into the third.
Visibility
Use visibility markers to signify who can access the information contained within a class. Private
visibility hides information from anything outside the class partition. Public visibility allows all
other classes to view the marked information. Protected visibility allows child classes to access
information they inherited from a parent class.
14
Figure:Visibility
Multiplicity (Cardinality)
Place multiplicity notations near the ends of an association. These symbols indicate the number of
instances of one class linked to one instance of the other class. For example, one company will
have one or more employees, but each employee works for one company only.
Figure: Multiplicity
Composition and Aggregation Composition is a special type of aggregation that denotes a strong ownership between Class A,
the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow
diamond to represent a simple aggregation relationship, in which the "whole" class plays a more
important role than the "part" class, but the two classes are not dependent on each other. The
diamond end in both a composition and aggregation relationship points toward the "whole" class
or the aggregate.
15
Figure: Composition and aggregation
2. USE CASE DIAGRAM
Use case diagrams model the functionality of a system using actors and use cases. Use cases are
services or functions provided by the system to its users.
Symbols and Notations System
Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the
system's boundaries.
Use Case Draw the use cases using ovals. Label the ovals with verbs that represent the system's
functions.
16
Actors
Actors are the users of a system. When one system is the actor of another system, label the
actor system with the actor stereotype.
Relationships
Illustrate relationships between actor and a use case with a simple line. For relationships among
use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates that
one use case is needed by another in order to perform a task. An "extends” relationship
indicates alternative options under a certain use case.
Figure : Use case Diagram for Bank Information System
17
BEHAVIOR DIAGRAM (DYNAMIC) Interaction Diagrams: The interaction diagrams are divided into
Sequence diagram
Collaboration diagram
3. SEQUENCE DIAGRAMS
Sequence diagrams describe interactions among classes in terms of an exchange of
messages over time. Symbols and Notations
Class roles Class roles describe the way an object will behave in context. Use the UML object symbol to
illustrate class roles, but don't list object attributes.
Activation
Activation boxes represent the time an object needs to complete task.
18
Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to
represent asynchronous messages. Asynchronous messages are sent from an object that will not
wait for a response from the receiver before continuing its tasks.
Various message types for Sequence
Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.
Destroying Objects
Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X.
19
Loops A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for
exiting the loop at the bottom left corner in square brackets [ ]4
4.COLLABORATION DIAGRAM A collaboration diagram describes interactions among objects in terms of sequenced messages.
Collaboration diagrams represent a combination of information taken from class, sequence, and
use case diagrams describing both the static structure and dynamic behavior of a system. Symbols and Notations
Class roles
Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but
don't list object attributes. Association roles
Association roles describe how an association will behave given a particular situation. Association roles can be drawn using simple lines labeled with stereotypes.
20
Messages
Unlike sequence diagrams, collaboration diagrams do not have an
explicit way to denote time and instead number messages in order of
execution. Sequence numbering can become nested using the Dewey
decimal system. For example, nested messages under the first message
are labeled 1.1, 1.2, 1.3, and so on. A condition for a message is usually placed in square
brackets immediately following the sequence number. Use a * after the sequence number to
indicate a loop.
5. ACTIVITY DIAGRAM
An activity diagram illustrates the dynamic nature of a system by modeling the flow of
control from activity to activity. An activity represents an operation on some class in the
system that results in a change in the state of the system. Typically, activity diagrams are
used to model workflow or business processes and internal operation. Because an activity
diagram is a special kind of state-chart diagram, it uses some of the same modeling
conventions. Symbols and Notations Action states
Action states represent the non-interruptible actions of objects.
Action Flow Action flow arrows illustrate the relationships among action states.
21
.
Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow
arrow from an action to an object means that the action creates or influences the object. An
object flow arrow from an object to an action indicates that the action state
uses the object.
Initial State
A filled circle followed by an arrow represents the initial action state.
Final State
An arrow pointing to a filled circle nested inside another
circle represents the final action state.
Decision
A diamond represents a decision with alternate paths. The outgoing alternates should be
labeled with a condition or guard expression. You can also label one of the paths "else."
22
Synchronization
A synchronization bar helps illustrate parallel transitions. Synchronization is also called
forking and joining.
Implementation diagrams:
Implementation diagrams can be divided into
o Component diagram
o Deployment diagram 6. COLLABORATION DIAGRAMS
Component diagram describes the organization of the physical components in a system. Symbols and Notations
Component
A component is a physical building block of the system. It is represented as a rectangle with tabs.
23
Interface
An interface describes a group of operations used or created by components.
Dependencies Draw dependencies among components using dashed arrows.
7. DEPLOYMENT DIAGRAMS
Deployment diagrams depict the physical resources in a system including nodes, components,
and connections. Symbols and Notations
Component
A node is a physical resource that executes code components.
24
Association Association refers to a physical connection between nodes.
Place components inside the node that deploys them.
1.8 THE UNIFIED PROCESS
Problems arose when large information systems were developed using the traditional
paradigm, especially when the resulting information systems were maintained. By the mid 1980s
it had become clear that a better paradigm was needed. The object oriented paradigm proved to
be the solution. Over the next 10 years more than 50 different object-oriented methodologies
were published. Three of the most successful methodologies were
Booch’s methodology
Jacobson’s Objectory.
Rumbaugh’s Object modeling Technique. Taking the information system world by storm with UML was not enough for the three Amigos.
Their next endeavor was to publish a complete object-oriented analysis and design methodology
that unified their three separate methodologies. This unified methodology was first called the
Rational Unified Process (RUP) [The word Rational because at that time all the three Amigos
were senior managers at Rational Inc.]
The unified process is a series of steps that will result in the constructions of an
information system. In fact, there is no such single “one size fits all” methodology could exist,
because there is such a wide variety of different types of information systems. For example, there
are different application domains, such as banking, insurance or manufacturing. Thus the Unified
Process can be viewed as an Adaptable methodology.
25
1.9 ITERATIVE AND INCREMENTAL WITHIN THE UNIFIED PROCESS
The Unified Process is a modeling technique. A model is a set of UML diagrams that
represent one or more aspects of the information system wanted to be developed. A major reason
for using a graphical representation is that UML diagrams enable information technology
professionals to communicate with one another more quickly and more accurately than if only
verbal descriptions were used.
The Unified Process is an iterative and incremental methodology. Each workflow
consists of a number of steps and in order to carry out that workflow, the steps of the workflow
are repeated until the members of the development team are satisfied that they have an accurate
UML model of the information system they want to develop. The implication is that system
analysts, no matter how outstanding they may be, almost never get the object-oriented analysis
and design right the first time.
It is been subjected to Miller’s law-that one cannot think about everything at the same
time, so a set of seven chunks or so can be handled at once and then another set where the
developer can gain more knowledge about the information system and modify the UML
diagrams in light of the additional information. Thus more knowledge about the real-world
system is gained to make more accurate (iteration) and is extended accordingly (incrementation)
until accurate representation of the information system is developed.