CA 5202 - Object Oriented Analysis and Design

CA 5202 – Object Oriented Analysis and Design
Chapter - 1
Object-Oriented (OO) Software Development Process (SDP)
Introduction
Software engineering is a systematic and disciplined methodology for producing reliable

and workable software using a suite of sound engineering principles. For any system to be
engineered and sustained, we need an array of trend-setting technologies, proven
processes, scalable infrastructures and adaptive resources including humans. Software
engineering also like other core engineering disciplines needs a host of standardized,
industrial-strength and well-defined development processes.
There are a bewildering array of software applications and types. Primarily software is
classified into two: system and application software. A typical system software mainly
interacts with the computer, its components and peripherals such as printer, webcam,
scanner, mouse, USB drive etc besides with all the network infrastructure solutions such
as routers, switches, bridges, hubs, gateways, etc. The application software generally
interacts with the system software. The details are as follows.
1.1 Software Types
System Software is a collection of programs written to service other programs. Some

system software such as program language compilers, interpreters and file systems process
complex, but determinate, information structures. Other system software, such as device
drivers, operating systems, protocols, etc, are destined to process largely indeterminate
data. Thus the primary characteristics of system software are as given below. It
• Needs to interact with computer hardware and other peripherals,
• Might be used by multiple applications and users
• Involves concurrent operation that requires scheduling, slicing, time & resource
sharing, and sophisticated process management
• Includes complex data structures and multiple external interfaces
Middleware is an emerging software type that sits in between application and system
software facilitating smooth interaction, collaboration, communication, integration,
connectivity, and adaptation purposes.
AVCCE, Dept. of MCA – III Semester 1

Real-time Software represents programs that monitor / analyze / control real world events
as they occur. Elements of real-time software include a data gathering component that
collects and formats information from an external environment, an analysis component
that transforms information as required by the application, a control / output component
that responds to the external environment, and a monitoring component that coordinates
all other components so that real-time response can be maintained. Thus a real-time
system must respond within strict time constraints.
Engineering and scientific software has been all along characterized primarily by
number crunching algorithms. Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and from molecular biology
to automated manufacturing. These are processing-intensive applications.
Embedded software is becoming hugely popular these days. They are found in consumer
electronics, avionics, handhelds, wearables, portables, mobiles, automobiles, smart homes,
and manufacturing industries. Embedded software resides in real-only memory and is used
to control products and systems for the consumer and industrial markets. Embedded
software can perform very limited and esoteric functions such as key pad control for a
microwave oven or provide significant function and control capabilities (e.g., digital
functions in an automobile such as fuel control, dashboard displays, braking systems etc.).
Communication software facilitates seamless mobility of mobile users and devices

besides ensuring reliable communication among devices.
Artificial Intelligence (AI) software makes use of non-numerical algorithms to solve

complex problems that are not amenable to computation or straightforward analysis. An
active area is expert systems, also called knowledge-based systems. Other areas of AI are
machine learning, natural language processing, speech recognition, pattern recognition,
theorem proving, game playing, etc. Incorporating intelligence inside the software are the
critical objective of AI
There are many application software applications such as web-based, wireless, desktop,
financial, enterprise, logistics, retail, energy, governmental, healthcare and other business
software applications. Business software represents the discrete systems such as
enterprise resource planning (ERP), supply chain management (SCM), customer
relationship management (CRM), inventory, knowledge, and content management. Most
of the business software are data intensive and data-processing applications.

Similarly there are promising methods, technologies, strategies, tools, infrastructures, and
resources. Thus an appropriate software development process model has to be strictly
chosen based on the nature of the final software system to be built. In this chapter, we are
to see the well-known development process models.
2. Development Process Models
2.1 The Linear Sequential Developmental Model for software engineering is called the
classic life cycle or the waterfall model. This model suggests a systematic, sequential
approach to software development that begins at the system level and progresses through
analysis, design, coding, testing and maintenance. Modeled after the conventional
engineering cycle, the linear sequential model encompasses the following activities:
• System / Information engineering and modeling – Because software is always

part of a larger system, work begins by establishing requirements for all system
elements and then allocating some subset of these requirements to software. This
system view is essential when software must interface with other elements such as
hardware, people, and databases. System engineering and analysis encompasses
requirements gathering at the system level with a small amount of top-level
analysis and design. Information engineering encompasses requirements gathering
at the strategic business level and at the business area level.
• Software requirement analysis – The requirements gathering process is

intensified and focused specifically on software. To understand the nature of the
programs to be built, the software engineer (analyst) must understand the
information domain for the software as well as required function, behavior,
performance, and interfacing. Requirements for both the system and the software
are documented and reviewed with the customer.
• Design –The design process translates software requirements into a representation

of the software that can be assessed for quality before code generation begins. Like
requirements, the design is documented and becomes part of the software
configuration.
• Code generation – The design must be translated into a machine readable form.
• Testing – Once code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, assuring that all statements

have been tested and on the functional externals – that is, conducting tests to
uncover errors and ensure that defined input will produce actual results that agree
with required results.
• Maintenance – Software will undoubtedly undergo change after it is delivered to

the customer.
The Prototyping Model – The prototyping paradigm begins with requirements gathering.
Developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
A quick design then occurs. The quick design focuses on a representation of those aspects
of the software that will be visible to the customer / user. The quick design leads to the
construction of a prototype. The prototype is evaluated by the customer / user and is used
to refine requirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, at the same time enabling the developer to
better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a

working prototype is built, the developer attempts to make use of existing program
fragments or applies that enable working programs to be generated quickly. Prototyping is
an effective paradigm for software engineering.
Rapid Application Development (RAD) model is a linear sequential software

development process model that emphasizes an extremely short development cycle. The
RAD model is a high-speed adaptation of the linear sequential model in which rapid
development is achieved by using a component-based construction approach. If
requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a fully functional system within very short time
periods. The RAD approach encompasses the following phases:
• Business modeling – The information flow among business functions is modeled

in a way that answers the following questions: what information drives the
business process? What information is generated? Who generates its? Where does
the information go? Who processes it?
• Data modeling – the information flow defined as part of the business modeling
phase is refined into a set of data objects that are needed to support the business.

The characteristics (attributes) of each object are identified and the relationships
between these objects are defined.
• Process modeling – the data objects defined in the data modeling phase are
transformed to achieve the information flow necessary to implement a business
function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object
• Application generation – RAD uses the fourth generation techniques to create

software.
• Testing and turnover – Since the RAD process emphasizes reuse, many of the
program components have already been testing.
2.2 Evolutionary Software Process Models – There is growing recognition that software,
like all complex systems, evolves over a period of time. Thus a few interesting
evolutionary models have emerged. Below a brief of each is supplied.
The Incremental model combines elements of the linear sequential model with the
iterative philosophy of prototyping. Each linear sequence produces a deliverable increment
of the software. For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production
functions in the first increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment. Thus when an
incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features remain undelivered. The
core product might be used by the customer or be subjected for detailed review. As a result
of use and / or evaluation, a plan is being developed for the next increment. The plan
addresses the modification of the core product to better meet the needs of the customer and
the delivery of additional features and functionality. This process gets repeated following
the delivery of each increment, until the complete product is produced. The iterative
process, like prototyping and other evolutionary approaches, is iterative in nature.
The Spiral Model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the linear sequential
model. In this spiral model, software is developed in a series of incremental releases.

During early iterations, increasingly more complete versions of the engineered system are
produced. The spiral model is divided into a number of task regions.
1. customer communication – tasks required to establish effective communication

between developer and customer
2. planning – tasks required to define resources, timelines, and other project related
information
3. risk analysis – tasks required to assess both technical and management risks
4. engineering tasks required to build one or more representations of the application
5. construction & release – tasks required to construct, test, install and provide user
support
6. customer evaluation – tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering stage and
implemented during the installation stage
Each of the six regions is populated by a series of subtasks that are adapted according to
the characteristics of the project to be undertaken. The spiral model is a realistic approach
to the development of large scale systems and software.
Thus far, we have seen both old and new process models for generic software engineering.
Sometimes the process is being termed as software development life cycle (SDLC). There
are several techniques for simplifying each phase of this development process. Traditional
approaches such as functional / procedure –oriented and structured methods (Structured
analysis, design and implementation) C is the primary structured programming language.
In the recent past, OO paradigm (OO analysis, design, programming, and testing) have
emerged in the software market. Due to its soaring popularity and acceptance among the
professionals as well as the customers, it has become the dominant paradigm as far as the
task of engineering software for various personal, business as well as system domains.
Equally OO paradigm is being strengthened and supported by the grand arrival of a host of
OO programming languages such as C++, Java, C#, VB.NET etc.
3. Object-Oriented Systems Development
We live in a world of objects. These objects exist in nature, in man-made entities, in

business and in the products we use everyday. They can be differentiated, categorized,
described, organized, combined, manipulated and created. Thus while forming software
abstractions for the real-world problems, it is logical, prudent and natural to think of
software solutions as an interacting, collaborating, and coexisting software objects. This
concept induced many to come out with an increasing array of OO technologies, methods,
models, and approaches. The interesting aspect of OO method includes realizing of
reusability. This reuse of program components leads to faster software development of
bug-free, quality-conscious, reusable, scalable, secure and flexible software applications.
Also OO software is easy to conceptualize, develop, deploy, manage, handle, use, and
maintain for analysts, architects, developers, administrators, and end users.
Building High-Quality Software - The software process transforms the users’ needs via
the application domain to a formidable software service / solution / product that satisfies
that sincerely satisfies those needs. Once the software is build, it is mandatory to check
whether the built software is free of errors, bugs, risks, dangers, defects and infirmities
besides it accomplishes all the core requirements, intentions and expectations of the users.
Thus customer satisfaction and delight is the main and focused target for software services
and solutions providers. There are two basic approaches for testing software systems. That
is, we can test a system according to how it has been built or what it should do. There are
four quality measures for evaluating a system: correspondence, correctness, verification,
and validation. Correspondence measures how well the delivered system matches the
needs of the operational environment, as described in the original requirements statement.
Validation is the task of predicting correspondence. True correspondence cannot be
determined until the system is fully built. Correctness measures the consistency of the
product requirements with respect to the design specification. Verification is the exercise
of determining correctness.
Correctness always is objective. That is, given a specification and a product, it should be
possible to determine if the product precisely satisfies the requirements of the
specification. Validation is always subjective. That is, it checks the appropriateness of the
specification itself. In hindsight, verification checks whether we build the product right
whereas the validation evaluates whether we build the right product. Validation begins as
soon as the project starts, but verification can begin only after a specification has been
accepted. Thus realizing high-quality software is ensured through these checks. OO
system development technologies, methodologies, strategies, tools, infrastructures and
resources are guaranteeing high-quality software. In the following, we are to discuss in
detail all about the OO software development.

The activities involved in developing software in an OO perspective are
1. OO Analysis using use case technique
2. OO Design
3. Prototyping
4. Component-based Development
5. Incremental Testing
3.1 The OO Analysis (OOA) phase of software development is concerned with

identifying the system requirements and determining all the classes and their relationship
to other classes in the problem domain. In order to understand the system requirements
fully, comprehensively and precisely, we need to identify the end users (customers) or the
actors who are going to handle and use the system after its completion. Scenarios are used
to help analysts and domain experts to understand the requirements cleanly as they are a
great way of examining the relationships between the users and the objects and the
interrelationships among the objects. Ivar Jacobson has coined the word “use case” for a
scenario. That is, a use case is a typical interaction between a user and a system that
fulfills users’ goals, tasks and needs.
Thus in order to fully understand all the interactions, collaborations, communications,

operations, behaviors, and exceptions happening among the system components and the
users, we need to extract and gather all the scenarios. Further on, the set of compact
scenarios or use cases are being captured and gleaned through a series of interviews with
the potential users, extracting answers for many questions from them, and through
observation of users while handling such kinds of target systems. Expressing these high-
level processes and interactions with customers in a scenario and analyzing it is referred to
as use-case modeling. The use case model represents the users’ view of the final system.
Looking at the physical objects in the system also provides vital clue and relevant
information towards the core software classes and objects in the target system solution.
For example, in an online course registration system in a university, the possible tangible
objects are students, course-list, teachers, registrar, etc. The intangible objects include data
tables, data entry screens, data structures, and so forth.
Thus gathering system requirements in the form of use cases, studying, analyzing,
prioritizing, organizing, cataloguing, and documenting them for future references,

estimating risks, identifying the relevant classes, and establishing the plausible
relationships between the objects of those classes are some of the important activities of
the OO analysis phase.
3.2 The goal of Object-Oriented Design (OOD) phase is to design the classes identified
during the earlier phase and the user interface. Identifying and defining additional objects
and classes that support implementation of the requirements are the other important tasks
in this very crucial and critical phase. If the design is right, the product or the system to be
built would be right. During interface design, there will be a need for thinking about
incorporating additional objects. The activities of the design phase are summarized as
follows
• Design and refine classes
• Design and refine attributes
• Design and refine methods
• Design and refine structures
• Design and refine associations
Thus designing and refining the class and object structures, components and their
collaborations are the leading activities of the design phase.
In the picture drawn using IBM Rational tool, there are two classes (Shape and Controller)
and two subclasses (Rectangle and Circle) of Shape class. Each class has its own attributes
and methods as indicated in the class diagram.

3.3 Prototyping – It is gaining momentum to construct a prototype of the some of the key
system components before embarking on full-fledged system development. As often told
that a picture is worth a thousand words, a prototype is worth a thousand pictures. A
prototype is a version of a software product developed in the early stages of the product’s
life cycle for specific, experimental purposes. A prototype enables to fully understand how
easy or difficult to implement certain aspects in the final commercial version. Also we can
understand what novel features need to be added or what sorts of risks are involved in
system development. A prototype is to tell an overall view of the system under
development. A prototype would clearly tell what sort of changes the developer has to
make, what sort of software toolkits, languages, and technologies need to be used etc.
Thus the benefits accrued out of prototyping are manifold including rescuing the project
from going down. The navigability, usability, and usefulness of user interfaces can be
enhanced with this prototyping. There are many commonly accepted prototypes as
follows.
1. A horizontal prototype is a simulation of the interface. In other words, it has the

entire user interface ready but contains no functionality.
2. A vertical prototype is a subset of the system features with complete functionality.

The advantage with this is that it is possible to thoroughly check the few
implemented functionality
3. An analysis prototype is an aid for exploring the problem domain. This class of
prototypes is used to inform the user and demonstrate the proof of a concept.

4. A domain prototype is an aid for the incremental development of the ultimate

software solution. It is often is used as an effective tool for the staged delivery of
subsystems to the users or other members of the development team. It
demonstrates the feasibility of the implementation and eventually will evolve into
a deliverable product.
Thus prototyping is turning out to be a useful exercise at almost any stage of the
development.
3.4 Component-based Development (CBD) – Manufacturers are adept in reusing and

assembling various prefabricated components for custom development. In the similar way,
software systems are being custom built easily, and quickly using a set of already
developed, tested, verified, validated, and deployed software components. There are
computer-aided software engineering (CASE) tools that helps to develop information
systems rapidly and seamlessly. The main goal of CASE technology is the automation of
the entire information system’s development life cycle process using a set of integrated
software tools, such as requirements gathering, storing, analyzing, modeling, designing,
debugging and automatic code generation. There are integrated development environments
(IDEs), compilers, editors, toolkits and other simplifying solutions that facilitate the
software development team immensely in satisfying the modern requirements of
accomplishing more with less (time, resources, investment, etc.).
Legacy applications coded using old technologies such as COBOL are made interoperable
with the modern applications using concepts such as wrapper, helper software suite etc.
Thus off-the-shelf components, wrappers, classes and other software modules are
encouraging the component-based development. The software components are the
functional units of a program and building blocks for offering a collection of core,
customized, and personalized services. Thus CBD is emerging as the hot cake for the
developers to develop next-generation software applications using the time-tested, quality-
conscious, refined, and highly reusable software components.
3.5 Rapid Application Development (RAD) is a set of software tools such as Delphi,
Visual Basic, VisualAge, or PowerBuilder and viable techniques that can be used to build
an application faster than typically possible with traditional methods. RAD is often
associated with development of software in quick time. The main objective of RAD is to
build a version of an application quickly to see whether the architects have understood the

system requirements correctly and the developers are moving in the right direction.
Further it determines whether the system does what it is expected to do. Thus RAD is an
interesting move in order to visualize what is to come and if there is any deviation, it can
be corrected in time.
3.6 Incremental testing – In the olden days, after fully completing the system or product
only, the testing team will come into picture. This will waste a lot of time and dollars and
hence in order to reduce the project completion time, testing is introduced at the earlier
stage. That is, when a small building block (a testable class or software module), it is sent
to testing department for thorough and comprehensive testing.
In summary, in the initial sections, we have discussed generic software development

process models, and subsequently we have concentrated on OO software development life
cycle (OO SDLC) as it is an accepted fact that OO paradigm is doing wonders for not only
producing object-oriented software but also for components and services that can be
accessed over the net (Intranet, the Internet and extranet).

UNIT - II
4. Object-Oriented Methodologies (OOM)
There are too many OO methodologies proposed by many and the top three are from
Booch, Rumbaugh, and Jacobson. In this chapter, we are to study each of these leading
OOM and at the end; we derive the unified approach by composing the best methods,
concepts, diagrams, and initiatives. The key concepts in Object-Oriented Programming are
these:
Classes - A class is the definition of the behavior and properties of one or more objects
within a system. A class binds the data (attributes) of an object to the behavior
(operations) that it can perform.
Attributes - An attribute is a data value or state that describes an object and helps to tell
one object from another of the same class. In some OO languages, these data values are
called properties or member variables or member data; but in UML, the proper term is
attributes.
Operations - An operation is a behavior or function that an object can perform.

Depending on the OO language, these might be called methods or member functions or
even messages. All objects communicated by sending messages to each other.
Objects - An object is an instance or specific example of a class. If Dog is the class, then
Betsy, Ladi, Patches, Jake, Radar, and Frosty are specific instances of the class found in a
house. The attributes of the class have specific values within an object of that class; and
the operations of a class operate on the attributes of individual objects.
Inheritance - This concept indicates that one class (the superclass) provides some
common or general behavior inherited by one or more specific classes (the subclasses).
The subclasses then provide more or different behavior beyond that defined in the
superclass. For example, besides the Dogs, I have Cat objects and Horse objects. Each
class has unique behaviors: Dogs must be walked, Cats use the litter box, and Horses drop
manure that must be scooped up and thrown in the manure pile. Yet all classes have some

common behavior: they must be fed, and they must have vet visits. So I can define a
superclass, Pet, and have my subclasses, Dog, Cat, and Horse, derive their shared behavior
from the Pet class. In UML, this concept is known under the slightly different term of
generalization, in which a superclass provides the generalized behavior of the subclasses.
Components - A component is a collection of related classes that together provide a larger

set of services. Components in our system might include applications, libraries, ActiveX
controls, JavaBeans, daemons, and services. In the .NET environment, most of the projects
will require component development.
Interfaces - An interface is a definition of a set of services provided by a component or by

a class. This allows further encapsulation: the author of a component can publish just the
interfaces to the component, completely hiding any implementation details.
Object-Oriented Methodology (OOM) is a set of proven methods, models, and rules for
developing systems. Modeling is the process of describing an existing or proposed system.
A model is an abstraction of a phenomenon for the purpose of understanding it. Since a
model excludes unnecessary details, it is easier to manipulate than the real object.
Modeling provides a means for communicating ideas in an easy to understand and
unambiguous form while also accommodating a system complexity.
To get a feel for object-oriented methodologies, in this section, we are to see look at some
of the methods
1. The Booch Method
2. Sally Shlaer and Steve Mellor have created the concept of the recursive design
approach
3. Beck and Cunningham produced class-responsibility-collaboration (CRC) cards
4. Wirfs-Brock, Wilkerson, and Wiener came up with responsibility-driven design
5. Jim Rumbaugh led a team at the research labs of General Electric to develop the
object modeling technique (OMT)
6. Peter Coad and Ed Yourdon developed the Coad lightweight and prototype-
oriented approach to methods

7. Ivar Jacobson introduced the concept of the use case and object-oriented software
engineering
Many methodologies are available for system development. Each methodology is based on
modeling the business problem and implementing the application in an object-oriented
fashion. These methodologies and many other forms of notational language have provided
system designers and architects many choices but created a very confusing environment.
Most of the methods were very similar but contained a number of often annoying minor
differences. The differences lie primarily in the documentation of information and
modeling notations and language.
1. Rumbaugh et al.’s object modeling technique (OMT)
The OMT describes a method for the analysis, design, and implementation of a system
using an object-oriented technique. MT is a fast, intuitive approach for identifying and
modeling all the objects making up a system. OMT separates modeling into three different
parts as described below.
 Object model describes the structure of objects in a system: their identity,

relationships to other objects, attributes, and operations. The object model is
graphically represented with an object diagram that contains classes interconnected
by association lines. Each class represents a set of individual objects. The
association lines establish relationships among the classes. Each association line
represents a set of links from the objects of one class to the objects of another
class.
 Dynamic model – OMT provides a detailed and comprehensive dynamic model,

in addition to letting to depict states, transitions, events and actions. The OMT
state transition diagram is a network of states and events. Each state receives one
or more events, at which time it makes the transition to the next state. The next
state depends on the current state as well as the events
 Functional model – The OMT data flow diagram (DFD) shows the flow of data
between different processes in a business. An OMT DFD provides a simple and
intuitive method for describing business processes without focusing on the details
of computer systems. Data flow diagrams use four primary symbols:

1. The process is any function being performed; for example, verify Password
or PIN in the ATM system
2. The data flow shows the direction of data element movement; for example,
PIN code
3. The data store is a location where data are stored; for example, account is a
data store in the ATM example
4. An external entity is a source or destination of a data element; for example,

the ATM card reader.
OMT consists of four phases, which can be performed iteratively:
1. Analysis – The results are object, dynamic, and functional models
2. System Design – The results are a structure of the basic architecture of the system
along with high-level strategy decisions
3. Object Design – This phase produces a design document, consisting of detailed

objects static, dynamic and functional models
4. Implementation – This activity produces reusable, workable and robust source

code
2. The Booch Methodology
Booch define methodology consists of a lot symbols to document almost every design
decision. The Booch method consists of the following diagrams
1. Class Diagrams
2. Object Diagrams
3. State Transition Diagrams
4. Module Diagrams
5. Process Diagrams
6. Interaction Diagrams
This methodology prescribes a macro development process and a micro development

process.

The macro process serves as a controlling framework for the micro process. The primary
concern of the macro process is technical management of the system. Such management is
interested less in the actual OO design and instead focus on how well the project
corresponds to the requirements set for it and whether it is produced on time.
The macro development process consists of the following steps:
1. Conceptualization – During this step, we establish the core requirements of the

system. Also we need to establish a set of goals and develop a prototype to prove
the concept.
2. Analysis and development of the model – We can use the class diagram to describe
the roles and responsibilities objects are to carry out in performing the desired
behavior of the system. We can use object diagram or the interaction diagrams to
describe the behavior of the system.
3. Design or create the system architecture – In this phase, we can use the class
diagram to decide what classes exist and how they relate to each other. Next, we
can use the object diagram to decide what mechanisms are used to regulate how
objects collaborate. Then we can use the module diagram to map out where each
class and object should be declared. Finally, we can use the process diagram to
determine to which processor to allocate a process. Also this step determines the
schedules for multiple processes on each relevant processor.
4. Evolution or Implementation – Successively refine the system through many

iterations. Produce a stream of software implementations, each of which is a
refinement of the prior one.
5. Maintenance – Make a localized changes to the system to add new requirements

and eliminate bugs
The Micro Development process – Each macro development process has its own micro
development process, which has the following steps.
1. Identify classes and objects
2. Identify class and object semantics
3. Identify class and object relationship

4. Identify class and object interfaces and implementation
3. Jacobson Methodology
The Jacobson et al. Methodologies (object-oriented business engineering (OOBE),

object-oriented software engineering (OOSE), referred to as Objectory) cover the entire
lifecycle and stress traceability between the different phases, both forward and backward.
This traceability enables reuse of analysis and design work in the reduction of
development time. At the heart of this OOM is the use case concept.
Use cases are scenarios for understanding system requirements. A use case is an
interaction between users and a system. The use case model captures the goal of the user
and the responsibility of the system to its users. The use cases are described as text, easy to
read with a clear flow of events to follow. The use case description must contain
 How and when the use case begins and ends
 The interaction between the use case and its actors, including when the interaction
occurs and what is exchanged
 How and when the use case will need data stored in the system or will store data in
the system
 Exceptions to the flow of events
 How and when concepts of the problem domain are handled
Every single use case should describe one main flow of events. An exceptional or
additional flow of events could be added. The exceptional use case extends another use
case to include the additional one. The use case model employs extends and uses
relationships. The “extends” relationship is used when we have one use case that is similar
to another use case but does a bit more. That is, it extends the functionality of the original
use case like a subclass. The uses relationship reuses common behavior in different use
cases.
Use cases could be viewed as concrete or abstract. An abstract use case is not complete
and has no actors that initiate it but is used by another use case. Abstract use cases also are
the ones that have “uses” or “extends” relationships.
OOSE, also called Objectory is a method of OO development with the specific aim to fit
the development of large, real-time systems. The development process, called use-case

driven development, stresses that use cases are involved in several phases of the
development including analysis, design, validation and testing. The use case scenario
begins with a user of the system initiating a sequence of interrelated events. The highlight
of this methodology is that by organizing the analysis and design models around
sequences that are both more usable and more robust, adapting more easily to changing
usage.
Objectory is built around several different models:
 The use-case model defines the outside (actors) and inside (use case) of the system
behavior
 Domain object model – The objects of the real-world are mapped into the domain
object model
 The analysis object model presents how the source code (implementation) should
be carried out and written
 The Implementation model represents the implementation of the system
 The test model constitutes the test plans, specifications and reports
Object-oriented Business engineering (OOBE) is object modeling at the enterprise

level. Use cases are again the central vehicle for modeling.
The analysis phase defines the system to be built in terms of the problem-domain object
model, the requirements model, and the analysis model. The analysis phase should not
take into account the actual implementation environment parameters. This sort of analysis
helps to reduce complexity and promotes maintainability over the life of the system since
the description of the system will be independent of hardware and software requirements.
That is, this model should be developed just enough to form a base of understanding for
the requirements model. The analysis process is iterative but requirements and analysis
models should be stable before moving on to subsequent models
Design and Implementation Phases – The implementation environment must be

identified for the design model. This includes factors such as DBMS, distribution of
process, and constraints due to programming language, available component libraries, and
incorporation of GUI tools etc. The analysis objects are translated into design objects that
fit the current implementation environment

Testing phase – There are many testing types – unit testing, integration testing, system
testing etc.
4. Design Patterns – An Overview
Patterns for Software Development - An emerging idea in systems development is that

the process can be improved significantly if a system can be analyzed, designed, and built
from prefabricated and predefined system components. There are commonly encountered
and difficult problems that are recurring and repetitive and hence a need arises for a
standard vocabulary for communicating insight and experience about these problems and
their solutions. This enforces the view of having a body of literature consisting of both the
identified problems and solutions to help software analysts, architects, and developers.
Thus the focus here is on inculcating the culture of document creation in order to support
sound engineering architecture, design, best practices, guidelines etc. as the documentation
immensely helps to categorize and communicate about solutions to recurring problems.
The pattern has a name to facilitate discussion, and the information it represents. The
documentation of a pattern, in essence, provides the contexts under which it is suitable and
the constraints and forces that may affect a solution or its consequences.
Communication about patterns is enabled by a vocabulary that describes the pattern and its
related components such as name, context, motivation, and solution. By classifying these
components and their nature such as the structural or behavioral nature of the solution, we
can categorize patterns. The concept of patterns and their documentation is becoming
popular among the software professionals. They are being extensively used for shortening
the development time and to enhance the quality of software solutions. The OO thinkers
have come out with the roles of design patterns. They could identify the key aspects of a
common design structure that make it useful for creating a reusable OO design. Further
more, design patterns identify the participating classes and instances, their roles, and
collaborations and the distribution of responsibilities. Patterns also describe whet they can
be applied, whether they can be applied in view of other design constraints, and the
consequences and trade-offs of their use.
Patterns and pattern languages should be able to generate whole, living structures. Part of
the desire to create architectures emulating life lies in the unique ability of living things to
evolve and adapt to their ever-changing environments. Similarly, a good software
architecture is about being adaptable and resilient to change. The successive application of

several patterns, each encapsulating its own problem and forces, unfolds a larger solution,
which emerges indirectly as a result of the smaller solutions.
Pattern Types - A pattern in waiting, which is not yet known to recur, is called a proto-
pattern. Generative patterns are patterns that not only describe a recurring problem, they
can tell us how to generate something and can be observed in the recurring system
architectures they helped shape. Non-generative patterns are static and passive. They
describe recurring phenomena without necessarily saying how to reproduce them. We
have to document generative patterns due to their significant contributions for efficient
software development.
Pattern Application Domains - Patterns are being largely used for software architecture
and design and more recently, for all aspects of software engineering, including
development organization, the software development process, project planning,
requirements engineering, and software configuration management. A good pattern will
do the following:
 It solves a problem. Patterns capture solutions, not just abstract principles or

strategies
 It is a proven concept. Patterns capture solutions with a track record, not theories
or speculation
 The solution is not obvious. The best patterns generate a solution to a problem
indirectly
 It describes a relationship. Patterns do not just describe modules, but describe

deeper system structures and mechanisms
 The pattern has a significant human component. All software serves human
comfort or quality of life; the best patterns explicitly appeal to aesthetics and
utility.
 A good pattern description should fully encapsulate all the forces that have an
impact on it

Pattern Templates - Each pattern must be expressed in the form of a rule (template),
which establishes a relationship between a context, a system of forces which arises
in that context, and a configuration, which allows these forces to resolve themselves
in that context. A pattern should contain certain essential components:
1. Name – Every pattern should contain a meaningful name, which may be a single
word or short phrase to refer to the pattern and the knowledge and structure it
describes.
2. Problem – A statement of the problem that describes its intent: the goals and
objectives it wants to reach within the given context and forces.
3. Context – The preconditions under which the problem and its solution seem to
recur and for which the solution is desirable. It can be thought of as the initial
configuration of the system before the pattern is applied to it.
4. Forces – A description of the relevant forces and constraints and how they interact
or conflict with one another and with the goals we wish to achieve. Forces reveal
the intricacies of a problem and define the kinds of trade-offs that must be
considered in the presence of the tension or dissonance they create.
5. Solution – Static relationships and dynamic rules describe how to realize the
desired outcome. This often is equivalent to giving instructions that describe how
to construct the necessary products. The description may encompass pictures,
diagrams, and prose that identify the pattern’s structure, its participants, and their
collaborations, to show how the problem is solved. The solution should describe
not only the static structure but also the dynamic behavior. The static structure tells
us the form and organization of the pattern but the behavioral dynamics is what
makes the pattern “come alive”.
6. Examples – One or more sample applications of the pattern that illustrate a specific
initial context; how the pattern is applied to and transforms that context and the
resulting context left in its wake. Examples help the reader to understand the
pattern’s use and applicability. Visual examples and analogies often can be very
useful.
7. Resulting Context – The state or configuration of the system after the pattern is
applied, including the consequences (both bad and good) of applying the pattern,

and other problems and patterns that may arise from the new context. It describes
the post conditions and side effects of the pattern. This is sometimes called a
resolution of forces because it describes which forces have been resolved, which
ones remain unsolved, and which patterns may now be applicable. Documenting
the resulting context produced by one pattern helps to correlate it with the initial
context of other patters.
8. Rationale – A justifying explanation of steps or rules in the pattern and also of the
pattern as a whole in terms of how and why it resolves its forces in a particular
way to be in alignment with desired goals, principles and philosophies. It explains
how the forces and constraints are orchestrated in concert to achieve a resonant
harmony. That is, how the pattern actually works, why it works, and why it is good
9. Related patterns share the common forces. They also have an initial or resulting
context that is compatible with the resulting or initial context of another pattern.
Such patterns might be predecessor patterns whose application leads to this pattern,
successor patterns whose application follows from this pattern, alternative patterns
that describe a different solution to the same problem but under different forces
and constraints, and codependent patterns that may be applied simultaneously with
this pattern.
10. Known Uses – The known occurrences and its applications within existing systems
need to be documented. This helps validate a pattern by verifying that it indeed is a
proven solution to a recurring problem.
Antipatterns – A pattern represents a best practice whereas an antipattern represents

worst practice or a lesson learned. Antipatterns come in two varieties:
 Those describing a bad solution to a problem that resulted in a bad

situation
 Those describing how to get out of a bad situation and how to proceed
from there to a good solution
Antipatterns are valuable as it helps to understand good solutions by seeing and

understanding bad solutions.
Capturing Patterns – A pattern should help its users to comprehend existing systems,
customize systems to fit user needs, and construct new systems. The process of looking for

patterns to document is called pattern mining. The following guidelines give what exactly
is a pattern.
 Focus on practicality – Patterns should describe proven solutions to recurring

problems
 Aggressive disregard of originality – Pattern writers do not need to be the original

inventor or discoverer of the solutions that they document
 Nonanonymous review – Pattern submissions are shepherded rather than reviewed.

The shepherd contacts the pattern authors and discusses with him or her how the
patterns might be clarified or improved on
 Writers’ workshops instead of presentations – Rather than being presented by the

individual authors, the patterns are discussed in writers’ workshops, open forums,
and mini conferences
 Careful editing – The pattern authors should have the opportunity to incorporate all
the comments and insights during the shepherding and writers’ workshops before
presenting the patterns in their finished form.
5. Frameworks
A framework is a set of cooperating classes that make up a reusable design for a specific
class of software. A framework provides architectural guidance by partitioning the design
into abstract classes and defining their responsibilities and collaborations. A developer
customizes a framework to a particular application by subclassing the composing instances
of framework classes. The framework captures the design decisions that are common to its
application domain. Frameworks thus emphasize design reuse over code reuse, though a
framework will usually include concrete subclasses we can put to work immediately. Thus
a framework is a way of presenting a generic solution to a problem that can be applied to
all levels in a development. Design and software frameworks are currently popular.
Why Frameworks? - Frameworks are a way of delivering application development

patterns to support best practice sharing during application development. The motivations
for frameworks are as follows. An experienced programmer almost never codes a new
program from scratch. He will use macros, copy libraries, and template-like code
fragments from earlier programs to make a short on a new one. Work on the new program
begins by filling in new domain-specific code inside the older structures

A seasoned business consultant who has worked on many consulting projects performing
data modeling almost never builds a new data model from scratch. Instead, he will make
use of model fragments that have been developed over time to help new modeling projects
hit the ground running.
Design Patterns Vs Frameworks - A single framework typically encompasses several

design patterns. In fact, a framework can be viewed as the implementation of a
system of design patterns. A framework is executable software, where design
patterns represent knowledge and experience about software. Frameworks are in a
way of a physical nature, while patterns are of a logical nature: Frameworks are the
physical realization of one or more software pattern solutions; patterns are the
instructions for how to implement those solutions
 Design patterns are more abstract than frameworks – Frameworks can be

embodied in code, but only examples of patterns can be embodied in code.
Frameworks are written using a programming language and reused directly. In
contrast, design patterns have to be implemented each time they are used. Design
patterns also explain the intent, trade-offs, and consequences of the design
 Design patterns are smaller architectural elements than frameworks – A typical

framework contains several design patterns but the reverse is never true
 Design patterns are less specialized than frameworks – Frameworks always have a
particular application domain. In contrast, design patterns can be used in nearly
any kind of application.
6. Unified Approach (UA)
This approach is based on the best practices that have proven successful in system
development and more specifically the work done by the stalwarts of OO paradigm. The
UA establishes a unifying and unitary framework around their works by utilizing the UML
to describe, model, and document the software development process. The main idea
behind this UA is to combine the best practices, processes, methodologies, and guidelines
along with UML notations and diagrams for better understanding OO concepts and
systems development. The UA revolves around the following processes
 Use case driven development
 Object-oriented analysis

 Object-oriented design
 Incremental development and prototyping
 Continuous testing
The methods and technology employed include
 UML used for modeling
 Layered approach for software development
 Repository for OO system development containing best practices, patterns and

frameworks
 Component-based development
The UA allows iterative development by allowing to go back and forth between the design
and modeling or analysis phases.
OOA – Analysis is the process of extracting the needs of a system and what the system
must do to satisfy the user requirements. The goal is to understand the domain of the
problem and the system’s responsibilities by understanding how the users or will use the
system. This is accomplishing by constructing several models of the system. The models
concentrate on describing what the system does rather than how it does it. Separating the
behavior of a system from the way it is implemented requires viewing the system from the
user’s perspective rather than that of the machine. OOA process consists of the following
steps:
1. Identify the Actors
2. Develop a simple business process model using UML Activity diagram
3. Develop the Use Case
4. Develop interaction diagrams
5. Identify classes
OOD – The UA utilizes Jacobson’s analysis and interaction diagrams, Booch’s object
diagrams and Rumbaugh’s domain model. Further more, by following Jacobson’s life
cycle model, we can produce designs that are traceable across requirements, analysis,
design, coding, and testing. OOD process consists of:

1. Designing classes, their attributes, methods, associations, structures, and protocols,

apply design axioms
2. Design the access layer
3. Design and prototype user interface
4. User satisfaction and usability tests based on the usage / use cases
5. Iterate and refine the design
Iterative Development and Continuous Testing – We must iterate and reiterate till we
are satisfied with the system. Since testing often uncovers design weaknesses, we need to
repeat the entire process, taking what we have learned and reworking our design or
moving on to reprototyping and retesting. During this iterative process, our prototypes will
be incrementally transformed into the actual application. The UA encourages the
integration of testing plans from day 1 of the project. Usage scenarios can be test scenarios
and use cases will drive the usability testing.
Unified Modeling Language (UML) – The UML merges the best of the notations used
by the three most popular analysis and design methodologies. UML is becoming the
universal for modeling OO systems. It is to express models of many different kinds and
purposes just as a programming language is used in different ways. The UA uses the UML
to describe and model the analysis and design phases of systems development.
7. The Layered Approach to Software Development
Most systems being developed today are two-layered architecture: interface and data. The
three-layered approach consists of a view or user interface, a business layer and an access
layer. The business layer contains all the objects that represent the business (both data and
behavior). This is where, the real objects such as Order, customer, inventory and invoice
exist. The responsibilities of business layer are: model the objects of the business and how
they interact to accomplish the business processes. These objects should not be responsible
for the following:
1. Displaying details – Business objects should have no special knowledge of how

they are being displayed and by whom. They are designed to be independent of
any particular interface so the details of how to display an object should exist in
the interface (view) layer of the object displaying it

2. Data access details – Business objects also should have no special knowledge of
data and its origin. It does not matter to the business model whether the data are
stored and retrieved via SQL or file I/O. The business objects need to know only to
whom to talk about being stored or retrieved.
A business model captures the static and dynamic relationships among a collection of
business objects. Static relationships include object associations and aggregations. For
example, a customer could have more than one account or an order could be aggregated
from one or more line items. Dynamic relationships show how the business objects
interact to perform tasks. For example, an order interacts with inventory to determine
product availability. An individual business object can appear in different business
models. Business models also incorporate control objects that direct their processes.
The user interface (View) layer – The UI layer consists of objects with which the user
interacts as well as the objects needed to manage or control the interface.
1. Responding to user interaction – The UI layer objects must be designed to

translate actions by the user, such as clicking on a button or selecting from a menu,
into an appropriate response. That response may be to open or close another
interface to send a message down into the business layer to start some business
process.
2. Displaying business objects - This layer must paint the best possible picture of the
business objects for the user. In one interface, this may mean entry fields and list
boxes to display an order and its items. In another, it may be a graph of the total
price of a customer’s orders.
The Access layer contains objects that know how to communicate with the place where
the data actually reside, whether it is a relational database, OODBMS. Regardless of
where the data actually reside, the objectives
1. Translate request – this layer must be able to translate any data-related requests
from the business layer into the appropriate protocol for data access. For example,
if customer number 55552 needs to retrieved, the access layer must be able to
create the correct SQL statement and execute it

2. Translate results – This layer also must be able to translate the data retrieved back
into the appropriate business objects and pass those objects back up into the
business layer.
8. The UA Repository
In modern businesses, best practice sharing is a way to ensure that solutions to process and
organization problems in one part of the business are communicated to other parts where
similar problem occur. Best practice sharing eliminates duplication of problem solving.
For many companies, best practice sharing is institutionalized as part of their constant goal
of quality improvement. Best practice sharing must be applied to application development
if quality and productivity are to be added to component reuse benefits.
The idea promoted here is to create a repository that allows the maximum reuse of
previous experiences, knowledge gathered and previously defined specifications, objects,
principles, practices, processes, procedures, software modules, classes, components,
services, and applications in an easily accessible manner with a completely available and
easily utilized format. Everything from the original user request to maintenance of the
project as it goes to production should be kept in the repository. The advantages of
repositories are many. If we store software objects from our projects implementations for
our clients in the repository, they can be reused for forthcoming projects. Any thing such
as the definition of data element, diagrams symbols, definitions, etc can be stored in the
repository. Thus software development becomes easier, and quicker. If new requirements
emerge, new objects will be design and stored in the main repository for future use. The
repository will be made available and accessible for many. Also there are UML diagrams,
design patterns, frameworks, CASE tools, IDEs etc that also facilitate quicker software
development.
Unified Modeling Language (UML)
What is model? - A model is an abstract representation of a system, constructed to

understand the system prior to building or modifying it. A model is a simplified
representation of reality, which is too complex or large and much of the complexity
actually is irrelevant to the problem we are trying to describe or solve. A model provides a
means for conceptualization and communication of ideas in a precise and unambiguous
form. Thus modeling is to cope up with the increasing complexity of systems. Models
make it easier to express complex ideas. Model reduces the complexity and enhances and

reinforces learning and training. Manipulation of the model is much easier than
manipulation of a real system.
Static & dynamic models
Why Models? - Models can represent static or dynamic models. A static model can be
viewed as a snapshot of a system’s parameters at rest or at a specific point in time. Static
models are needed to represent the structural or static aspect of a system. For example, a
customer could have more than one account or an order could be aggregated from one or
more line items. Static models assume stability and an absence of change of data over
time. The class diagram is an example of a static model
A dynamic model can be viewed as a collection of procedures or behaviors that, taken

together, reflect the behavior of a system over time. Dynamic relationships show how the
business objects interact to perform tasks. For example, an order interacts with inventory
to determine product availability. Dynamic modeling is useful during design and
implementation phases of the system development. The interaction and activity diagrams
are dynamic models.
A modeling language must include
 Model elements – fundamental modeling concepts and semantics
 Notation –visual rendering of model elements
 Guidelines – expression of usage within the state
Due to the rise in complexity of present day systems, virtualization and modeling becomes
essential, as we cannot comprehend the total system. Visual notations bring us several
benefits relating to
Clarity – We are much better at picking out errors, and omissions from a graphical or
visual representation than from listings of code or tables of numbers
Familiarity – The representation form for the model may turn out to be similar to the way
in which the information actually is represented and used by the employees currently
working in the problem domain.
Maintenance – Visual notation can improve the maintainability of a system. The visual
identification of locations to be changed and the visual confirmation of those changes will
reduce errors.

Simplification – Use of higher-level representation generally results in the use of fewer

but more general constructs contributing to simplicity and conceptual understanding
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 rules and semantics are expressed in English in a form known as
object constrain language (OCL), which is a specification language that uses simple logic
for specifying the properties of a system. The primary goals in the design of the UML
were
1. Provide users a ready-to-use, expressive visual modeling language so they can

develop and exchange meaningful models
2. Provide extensibility and specialization mechanisms to extend the core concepts
3. Be independent of particular programming language and development process
4. Provide a formal basis for understanding the modeling language
5. Encourage the growth of the OO tools market
6. Support high-level development concepts
7. Integrate best practices and methodologies
UML Diagrams
1. Class diagram
2. Use-case diagram
3. Behavior diagram
3.1 Interaction diagram
3.1.1 Sequence diagram
3.1.2 Collaboration diagram
3.2 State chart diagram
3.3 Activity diagram
4. Implementation diagram
4.1 Component diagram

4.2 Deployment diagram
The UML class diagram, also referred to as object modeling, is the main static analysis
diagram. These diagrams show the static structure of the model. A class diagram is a
collection of static modeling elements such as classes and their relationships, connected as
a graph to each other and to their contents. Object modeling is the process by which the
logical objects in the real world (problem space) are represented (mapped) by the actual
objects in the program (logical world). The visual representation of the objects, their
relationships and their structures is for ease of understanding. It is essential to determine
all the objects required for the system. The main task of object modeling is to graphically
show what each object will do in the problem domain, describe the structure such as class
hierarchy and the relationships among objects by visual notation and determine what
behaviors fall within and outside the problem domain.
Use Case Diagram – The functionality of a system is described in a number of different

use cases, each of which requires a specific flow of events in the system. A use case
corresponds to a sequence of transactions, in which each transaction is invoked from
outside the system (actors) and engages internal objects to interact with one another and
with the system’s surroundings. The description of a use case defines what happens in the
system when the use case is performed. In essence, the use case model defines the outside
(actors) and inside (use cases) of the system’s behavior. The use cases are initiated by
actors and describe the flow of events that these actors set off. An actor is anything that
interacts with a use case. An actor could be a human user, external hardware, or another
system. A use case diagram is a graph of actors, a set of use cases enclosed by a system
boundary, communication associations between the users and the use cases and
generalization among the use cases.
Dynamic Modeling
We need to understand both the structure and the function of the objects involved. We
must understand the taxonomic structure of class objects, the inheritance and mechanisms
used the individual behaviors of objects, and the dynamic behavior of the system as a
whole. Events happen dynamically in all systems. Objects are created, and destroyed.
Objects sends messages to one another in an orderly fashion and in some systems, external
events trigger operations on certain objects. Further more, objects have states and static
model fails to capture the state of an object. The state of an object is the result of its

behavior. Each class may have an associated activity diagram that indicates the behavior
of the class’s instance (its object).
UML Interaction diagrams describe how groups of objects collaborate to get the job done.
Interaction diagrams capture the behavior of a single use case, showing the pattern of
interaction among objects.
Sequence Diagram is an easy and intuitive way of describing the behavior of a system by
viewing the interaction between the system and its environment. A sequence diagram
shows an interaction arrange in a time sequence. It shows the objects participating in the
interaction by their lifelines and the messages they exchange, arranged in a time sequence.
A sequence diagram has two dimensions: the vertical dimension represents time, the
horizontal dimension represents the different objects. The vertical line is called the
object’s lifeline that represents the object’s existence during the interaction. Each message
is represented by an arrow between the lifelines of two objects. The order in which these
messages occur is shown top to bottom on the page. Each message is labeled with the
message name. A sequence diagram is an alternative way to understand the overall flow of
the control of a program.
UML Collaboration diagram – This represents a collaboration, which is a set of objects

related in a particular context, and interaction, which is a set of messages exchanged
among the objects within the collaboration to achieve a desired outcome. In this diagram,
objects are shown as figures and arrows indicate the message sent within the given use
case. The sequence is indicated by numbering the messages. In this diagram, the layout
indicates how objects are statically connected.
The disadvantage of interaction diagrams is they are great only for representing a single
sequential process. They begin to break down when we want to represent conditional
looping behavior. However, there are ways to represent condition behavior in interaction
diagrams. The preferred method is to use separate diagrams for each scenario. Another
way is to use conditions on messages to indicate the behavior. Activity diagram is the best
option for capturing complex behavior. Thus interaction diagrams are for examining the
behavior of objects within a single use case.
UML State-chart diagram – A state diagram shows the sequence of states that an object
goes through during its life in response to outside stimuli and messages. The state is the
set of values that describes an object at a specific point in time and is represented by state

symbols and the transitions are represented by arrows connecting the state symbols. A
state diagram may contain subdiagrams. A state diagram represents the state of the method
execution, that is, the state of the object executing the method. The activities in the
diagram represent the activities of the object that performs the method. The purpose of the
state diagram is to understand the algorithm involved in performing a method. The activity
symbol (a solid black dot) appears within a state symbol, it indicates the execution of an
operation.
A message is data passed from one object to another. A message is a name that will trigger
an operation associated with the target object. For example, an Employee object that
contains the name of an employee. If the employee object received a message
(getEmployeeName) asking for the name of the employee, an operation contained in the
Employee class would be invoked. That operation would check the attribute Employee
and then assign the value associated with that attribute back to the object that sent the
message in the first place. In this case, the state of the Employee object would not have
been changed. Now consider a situation where the same Employee object received a
message (updateEmployeeAddress). In this case, the object would invoke an operation
from its class that would modify the value associated with the attribute Employee,
changing it from the old address to the new address and hence the state of the employee
object has been changed.
A state is represented as a rounded box, which may contain one or more compartments.
The name compartment holds the optional name of the state and the internal transition
compartment holds a list of internal actions or activities performed in response to events
received while the object is in the state, without changing states.
Two special events are entry and exist. The statechart supports nested state machines. The
transition can be simple or complex. A simple transition is a relationship between two
states indicating that an object in the first state will enter the second state and perform
certain actions when a specific event occurs. A complex transition may have multiple
source and target states. It represents a synchronization or a splitting of control into
concurrent threads.
There is no need to prepare a state diagram for each class in the system. State diagrams are
useful if there is a dynamic class. In that situation, it is helpful to prepare a state diagram
to be sure we understand each of the possible states an object of the class could take and

what event (message) would trigger each transition from one state to another. In effect,
state diagrams emphasize the use of events and states to determine the overall activity of
the system
UML Activity Diagram is a variation or special case of a state machine, in which the
states are activities representing the performance of operations and the transitions are
triggered by the completion of the operation. Unlike state diagrams that focus on the
events occurring to a single object as it responds to messages, an activity diagram can be
used to model an entire business process. The purpose of an activity diagram is to provide
a view of flows and what is going on inside a use case or among several classes. Activity
diagram is also used to represent a class’s method implementation.
An activity model is similar to state diagram, where a token (a black dot) represents an
operation. An activity is shown as a round box, containing the name of the operation.
When an operation symbol appears within an activity diagram, it indicates the execution
of the operation. An outgoing solid arrow attached to an activity symbol indicates a
transition triggered by the completion of the activity. Several transitions with different
conditions imply a branching off of control.
An activity diagram is mostly used to show the internal state of an object. Activity and
state diagrams express a decision when conditions are used to indicate possible transitions
that depend on Boolean conditions of container object.
Implementation Diagram shows the implementation phase of systems development, such

as the source code structure and the run-time implementation structure. There are two
types of implementation diagrams: Component diagrams show the structure of the code
itself and deployment diagrams show the structure of the runtime system.
Component diagrams model the physical components (such as source code, executable
diagram, user interface) in a design. A package is a collection of classes, which are smaller
scale components. A package is being used to group logical components of the application
such as classes and not necessarily physical components. A component diagram is a graph
of the design’s components connected by dependency relationships.
Deployment diagrams show the configuration of run-time processing elements and the
software components, processes, and objects that live in them. Software component
instances represent run-time manifestations of code units. In most cases, component
diagrams are used in conjunction with deployment diagrams to show how physical

modules of code distributed on various hardware platforms. A deployment diagram is a

graph of nodes connected by communication association. Nodes may contain component
instances, which mean that the component lives or runs at that node. Components may
contain objects; this indicates that the object is part of the component. Components are
connected to other components by dashed-arrow dependencies, usually through interfaces,
which indicate one component uses the services of another. Each node or processing
element in the system is represented by a three-dimensional box. Connections between the
nodes themselves are shown by solid lines.
Packages – A package is a grouping of model elements. Packages themselves contain

other packages. The entire system can be thought of as a single high-level package with
everything else in it. All UML model elements and diagrams can be organized into
packages. A package is represented as a folder shown as a large rectangle with a tab
attached to its upper left corner. Hierarchical structure is there for packages with one
package is dependent on other packages. Packages can used to designate not only logical
and physical groupings but also use case groups. A use-case group is a package of use
cases.
UML Extensions
A note is a graphic symbol containing textual information and it also could contain
embedded images. A note is shown as a rectangle with a bent corner in the upper right
corner.
Stereotype represents a built-in extensibility mechanism of the UML. User-defined

extensions of the UML are enabled through the use of stereotypes and constraints. A
stereotype is a new class of modeling element introduced during modeling. It represents a
subclass of an existing modeling element with the same form but a different intent. UML
stereotypes extend and tailor the UML for a specific domain or process. The general
presentation of a stereotype is to use a figure for the base element but place a keyword
string above the name of the element. The stereotype allows extension of UML notation as
well as a graphic figure, texture, and color.
UML meta-model
The UML defines notations as well as a meta-model. UML graphic notations can be used
not only to describe the system’s components but also to describe a model itself. This is
known as meta-model. That is, a meta-model is a model of modeling elements. The

purpose of the UML meta-model is to provide a single common and definitive statement
of the syntax and semantics of the elements of the UML
The meta-model provides us a means to connect different UML diagrams. The connection
between the different diagrams is very important and the UML attempts to make these
couplings more explicit through defining the underlying model while imposing no
methodology.
UNIT - IV
Object-Oriented Design (OOD)
The main focus of the analysis phase of software development is on “what needs to be
done”. The objects discovered during analysis can serve as the framework for design. The
class’s attributes, methods and associations identified during analysis must be designed for
implementation as a data type in the implementation language. New classes must be
introduced to store intermediate results during program execution. Emphasizes shifts from
the application domain to implementation and computer concepts such as user interfaces
and access layer.
During the analysis, we look at the physical entities or business objects in the system.
These objects represent tangible elements of the business. These objects could be
individuals, organizations, machines, or something that makes sense in the context of the
real-world system. During the design phase, we must elevate the model into actual objects
that can perform the required task
The OO Design Process consist of the following activities
1. Apply design axioms to design classes, their attributes, methods, associations,

structures, and protocols.
 Refine and complete the static UML class diagram by adding details to
the UML class diagram. This step consists of the following
1. Refine attributes
2. Design methods and protocols by utilizing a UML activity

diagram to represent the method’s algorithm
3. Refine associations between classes

4. Refine class hierarchy and design with inheritance
 Create mirror classes – For every business class identified and created,
create one access class.
 Identify access layer class relationships
 Simplify classes and their relationships
3. Design the view layer classes
 Design the macro level user interface, identifying view layer objects
 Design the micro level user interface, which includes these

activities
1. Design the view layer objects by applying the design axioms

and corollaries
2. Build a prototype of the view layer interface
4. Iterate and refine the whole design
Utilizing an incremental approach such as the UA, all stages of software development can
be accomplished incrementally. From the UML class diagram, we can begin to
extrapolate which classes we will have to build and which existing classes we can reuse.
OO Design Axioms
By definition, an axiom is a fundamental truth that always is observed to be valid

and for which there is no counterexample or exception. Axioms may be
hypothesized from a large number of observations by noting the common
phenomena shared by all cases. A theorem is a proposition that may not be self-
evident, but can be proven from accepted axioms. A corollary is a proposition that
follows from an axiom or another proposition that has been proven. Suh’s OO
design axioms
1. The independence axiom
2. The information axiom

Axiom 1 states that during the design process, as we go from requirement and use case to
a system component, each component must satisfy that requirement without affecting
other requirements. Axiom 2 is concerned with simplicity. That is, software components
should be with a minimum amount of complexity and maximum simplicity and
straightforwardness.
Corollaries – From the above two design axioms, many corollaries may be derived as a
direct consequence of the axioms. These corollaries may be more useful in making
specific design decisions, since they can be applied to actual situations more easily than
the original axioms. The corollaries are design rules.
Corollary 1 – Uncoupled design with less information content – Highly cohesive objects
can improve coupling because only a minimal amount of essential information needs to be
passed between objects.
Coupling is a measure of the strength of association established by a connection from one

object or software component to another. That is, change in one component of a system
should have a minimal impact on other components. Strong coupling among objects
complicates a system. The degree or strength of coupling between two components is
measured by the amount and complexity of information transmitted between them.
Coupling becomes lower when the connection is to the component interface rather than to
an internal component. Coupling is also lower for data connections than for control
connections. OO design interaction coupling as well as inheritance coupling.
Interaction coupling involves the amount and complexity of messages between

components. Thus it is desirable to have little interaction. The general guideline is to keep
the messages simple and infrequent as possible. Also reduce the number of messages sent
and received by an object. Inheritance is a form of coupling between super and subclasses.
A subclass is coupled to its superclass in terms of attributes and methods. Unlike
interaction coupling, inheritance coupling is desirable.
Cohesion – Coupling deals with interactions between objects or software components.

Cohesion deals with interactions within a single object or component. Cohesion reflects
the single purpose of an object. Highly cohesive components can lower coupling because
only a minimum of essential information need to be passed between components.
Cohesion also helps in designing classes that have very specific goals and clearly defined
purposes.

Method cohesion means that a method should carry only one function. A method that
carries multiple functions is undesirable. Class cohesion means that all the class’s methods
and attributes must be highly cohesive meaning to be used by internal methods or derived
classes’ methods.
Corollary 2 – Single purpose – Each class must have a purpose. Every class should be
clearly defined. When we document a class, we should be able to do it in a sentence or
two. That is, keep it simple, precise and concise. Each method should provide only one
service.
Corollary 3 – Large number of Simpler Classes and Reusability – A great benefit results
from having a large number of simpler classes. The less specialized the classes are, the
more likely future problems can be solved by a recombination of existing classes, adding a
minimal number of subclasses. The primary benefit of reusability is higher productivity
Corollary 4 – Strong mapping – OOA and OOD are based on the same model. As the
model progresses from analysis to implementation, more detail is added, but it remains
essentially the same. For example, during analysis, we might identify a class “Employee”.
During the design phase, we need to design this class – design its methods, its association
with other objects and its view and access classes. A strong mapping links classes
identified during analysis and classes designed during the design phase
Corollary 5 - Standardization – Several OO languages have come out with built-in class
libraries. So to reuse classes, we need to have a good understanding of the classes in OO
environment. So class libraries need to be well documented. In essence, standardization of
classes and their libraries is the primary need.
Corollary 6 – Designing with Inheritance – We have to choose inheritance to minimize

the amount of program instructions. Single inheritance means that each class has only a
single superclass. The benefit of single inheritance is the absence of ambiguity as to how
an object will respond to a given method. Multiple inheritance scheme enforces objects to
inherit behavior from many superclasses. Multiple inheritance brings with it some
complications, such as how to determine which behavior to get from which class,
particularly several ancestors (superclasses) define the same method.
How to decide inheritance – There are possibilities for designing subclasses that inherit
from inappropriate superclasses. So the questions to be asked are

 Is the subclass fundamentally similar to its superclass (high inheritance coupling)?
 Is it an entirely new thing that simply wants to borrow some expertise from its
superclass (low inheritance coupling)?
One way of achieving the benefits of multiple inheritance in a language with single
inheritance is to inherit from the most appropriate class and add an object of another class
as an attribute or aggregation. Thus there are two ways to borrow existing functionality in
a class. One is to inherit it and the other is to use the instance (object) of the class as an
attribute.
Design Patterns
As we studied in a earlier chapter, a design pattern provides a scheme for refining the
subsystems or components of a software system or the relationships among them. In other
words, they are devices that allow systems to share knowledge about their design, by
describing commonly recurring structures of communicating components that solve a
general design problem within a particular context. For example, while programming, we
have encountered many problems that occurred before and will occur again. Here comes a
design pattern by Kurotsuchi
Pattern Name: Façade
Rationale and Motivation – The façade pattern can make the task of accessing a large
number of modules much simpler by providing an additional interface layer. When
designing good programs, programmers usually attempt to avoid excess coupling between
modules / classes. Using this pattern to simplify much of the interfacing. That is, a small
collection of classes will access a single class, which is the façade.
Classes – There can be any number of classes in this façade system but at least four or
more classes are required
Examples – If we are asked to write a program that needs to represent a building as

collection of rooms. Interacting with rooms means manipulating all the objects (screens,
windows, projectors, etc) in the rooms. The application architect could decide that the
façade pattern will be an excellent way to keep the amount of interfacing low. A sample
action for a room is to “prepare it for a presentation”. The client will command this action
on the façade class, which in turn do the connectivity with the concerned room and
manipulate the room components.

Object-Oriented Methodologies (OOM)
There are too many OO methodologies proposed by many and the top three are from
Booch, Rumbaugh, and Jacobson. In this chapter, we are to study each of these leading
OOM and at the end, we derive the unified approach by composing the best methods,
concepts, diagrams, and initiatives. The key concepts in Object-Oriented Programming are
these:
Classes - A class is the definition of the behavior and properties of one or more objects
within a system. A class binds the data (attributes) of an object to the behavior
Attributes - An attribute is a data value or state that describes an object and helps to tell
one object from another of the same class. In some OO languages, these data values are
called properties or member variables or member data; but in UML, the proper term is
attributes.
Operations - An operation is a behavior or function that an object can perform.

Depending on the OO language, these might be called methods or member functions or
even messages. All objects communicated by sending messages to each other.
Objects - An object is an instance or specific example of a class. If Dog is the class, then
Betsy, Ladi, Patches, Jake, Radar, and Frosty are specific instances of the class found in a
house. The attributes of the class have specific values within an object of that class; and
the operations of a class operate on the attributes of individual objects.
Inheritance - This concept indicates that one class (the superclass) provides some
common or general behavior inherited by one or more specific classes (the subclasses).
The subclasses then provide more or different behavior beyond that defined in the
superclass. For example, besides the Dogs, I have Cat objects and Horse objects. Each
class has unique behaviors: Dogs must be walked, Cats use the litter box, and Horses drop
manure that must be scooped up and thrown in the manure pile. Yet all classes have some
common behavior: they must be fed, and they must have vet visits. So I can define a
superclass, Pet, and have my subclasses, Dog, Cat, and Horse, derive their shared behavior
from the Pet class. In UML, this concept is known under the slightly different term of
generalization, in which a superclass provides the generalized behavior of the subclasses.

Components - A component is a collection of related classes that together provide a larger

set of services. Components in our system might include applications, libraries, ActiveX
controls, JavaBeans, daemons, and services. In the .NET environment, most of the projects
will require component development.
Interfaces - An interface is a definition of a set of services provided by a component or by

Object-Oriented Methodology (OOM) is a set of proven methods, models, and rules for
developing systems. Modeling is the process of describing an existing or proposed system.
A model is an abstraction of a phenomenon for the purpose of understanding it. Since a
model excludes unnecessary details, it is easier to manipulate than the real object.
Modeling provides a means for communicating ideas in an easy to understand and
unambiguous form while also accommodating a system complexity.
To get a feel for object-oriented methodologies, in this section, we are to see look at some
of the methods
1. The Booch Method
2. Sally Shlaer and Steve Mellor have created the concept of

the recursive design approach
3. Beck and Cunningham produced class-responsibility-

collaboration (CRC) cards
4. Wirfs-Brock, Wilkerson, and Wiener came up with

responsibility-driven design
5. Jim Rumbaugh led a team at the research labs of General

Electric to develop the object modeling technique (OMT)
6. Peter Coad and Ed Yourdon developed the Coad lightweight

and prototype-oriented approach to methods
7. Ivar Jacobson introduced the concept of the use case and

object-oriented software engineering
Many methodologies are available for system development. Each methodology is based on
modeling the business problem and implementing the application in an object-oriented

fashion. These methodologies and many other forms of notational language have provided
system designers and architects many choices but created a very confusing environment.
Most of the methods were very similar but contained a number of often annoying minor
differences. The differences lie primarily in the documentation of information and
modeling notations and language.
1. Rumbaugh et al.’s object modeling technique (OMT)
The OMT describes a method for the analysis, design, and implementation of a system
using an object-oriented technique. MT is a fast, intuitive approach for identifying and
modeling all the objects making up a system. OMT separates modeling into three different
parts as described below.
 Object model describes the structure of objects in a system: their identity,

relationships to other objects, attributes, and operations. The object model is
graphically represented with an object diagram that contains classes interconnected
by association lines. Each class represents a set of individual objects. The
association lines establish relationships among the classes. Each association line
represents a set of links from the objects of one class to the objects of another
class.
 Dynamic model – OMT provides a detailed and comprehensive dynamic model,

in addition to letting to depict states, transitions, events and actions. The OMT
state transition diagram is a network of states and events. Each state receives one
or more events, at which time it makes the transition to the next state. The next
state depends on the current state as well as the events
 Functional model – The OMT data flow diagram (DFD) shows the flow of data
between different processes in a business. An OMT DFD provides a simple and
intuitive method for describing business processes without focusing on the details
of computer systems. Data flow diagrams use four primary symbols:
1. The process is any function being performed; for example, verify Password
or PIN in the ATM system
2. The data flow shows the direction of data element movement; for example,
PIN code

3. The data store is a location where data are stored; for example, account is a
data store in the ATM example
4. An external entity is a source or destination of a data element; for example,

the ATM card reader.
OMT consists of four phases, which can be performed iteratively:
1. Analysis – The results are object, dynamic, and functional

models
2. System Design – The results are a structure of the basic

architecture of the system along with high-level strategy decisions
3. Object Design – This phase produces a design document,

consisting of detailed objects static, dynamic and functional models
4. Implementation – This activity produces reusable,

workable and robust source code
2. The Booch Methodology
Booch define methodology consists of a lot symbols to document almost every design
decision. The Booch method consists of the following diagrams
1. Class Diagrams
2. Object Diagrams
3. State Transition Diagrams
4. Module Diagrams
5. Process Diagrams
6. Interaction Diagrams
This methodology prescribes a macro development process and a micro development

process.
The macro process serves as a controlling framework for the micro process. The primary
concern of the macro process is technical management of the system. Such management is
interested less in the actual OO design and instead focus on how well the project
corresponds to the requirements set for it and whether it is produced on time. The macro
development process consists of the following steps:

1. Conceptualization – During this step, we establish the core requirements of the

system. Also we need to establish a set of goals and develop a prototype to prove
the concept.
2. Analysis and development of the model – We can use the class diagram to describe
the roles and responsibilities objects are to carry out in performing the desired
behavior of the system. We can use object diagram or the interaction diagrams to
describe the behavior of the system.
3. Design or create the system architecture – In this phase, we can use the class
diagram to decide what classes exist and how they relate to each other. Next, we
can use the object diagram to decide what mechanisms are used to regulate how
objects collaborate. Then we can use the module diagram to map out where each
class and object should be declared. Finally, we can use the process diagram to
determine to which processor to allocate a process. Also this step determines the
schedules for multiple processes on each relevant processor.
4. Evolution or Implementation – Successively refine the system through many

iterations. Produce a stream of software implementations, each of which is a
refinement of the prior one.
5. Maintenance – Make a localized changes to the system to add new requirements

and eliminate bugs
The Micro Development process – Each macro development process has its own micro
development process, which has the following steps.
1. Identify classes and objects
2. Identify class and object semantics
3. Identify class and object relationship
4. Identify class and object interfaces and implementation
3. Jacobson Methodology
The Jacobson et al. Methodologies (object-oriented business engineering (OOBE),

object-oriented software engineering (OOSE), referred to as Objectory) cover the entire
lifecycle and stress traceability between the different phases, both forward and backward.

This traceability enables reuse of analysis and design work in the reduction of
development time. At the heart of this OOM is the use case concept.
Use cases are scenarios for understanding system requirements. A use case is an
interaction between users and a system. The use case model captures the goal of the user
and the responsibility of the system to its users. The use cases are described as text, easy to
read with a clear flow of events to follow. The use case description must contain
 How and when the use case begins and ends
 The interaction between the use case and its actors, including when the interaction
occurs and what is exchanged
 How and when the use case will need data stored in the system or will store data in
the system
 Exceptions to the flow of events
 How and when concepts of the problem domain are handled
Every single use case should describe one main flow of events. An exceptional or
additional flow of events could be added. The exceptional use case extends another use
case to include the additional one. The use case model employs extends and uses
relationships. The “extends” relationship is used when we have one use case that is similar
to another use case but does a bit more. That is, it extends the functionality of the original
use case like a subclass. The uses relationship reuses common behavior in different use
cases.
Use cases could be viewed as concrete or abstract. An abstract use case is not complete
and has no actors that initiate it but is used by another use case. Abstract use cases also are
the ones that have “uses” or “extends” relationships.
OOSE, also called Objectory is a method of OO development with the specific aim to fit
the development of large, real-time systems. The development process, called use-case
driven development, stresses that use cases are involved in several phases of the
development including analysis, design, validation and testing. The use case scenario
begins with a user of the system initiating a sequence of interrelated events. The highlight
of this methodology is that by organizing the analysis and design models around

sequences that are both more usable and more robust, adapting more easily to changing
usage. Objectory is built around several different models:
 The use-case model defines the outside (actors) and inside (use case) of the system
behavior
 Domain object model – The objects of the real-world are mapped into the domain
object model
 The analysis object model presents how the source code (implementation) should
be carried out and written
 The Implementation model represents the implementation of the system
 The test model constitutes the test plans, specifications and reports
Object-oriented Business engineering (OOBE) is object modeling at the enterprise

level. Use cases are again the central vehicle for modeling.
The analysis phase defines the system to be built in terms of the problem-domain object
model, the requirements model, and the analysis model. The analysis phase should not
take into account the actual implementation environment parameters. This sort of analysis
helps to reduce complexity and promotes maintainability over the life of the system since
the description of the system will be independent of hardware and software requirements.
That is, this model should be developed just enough to form a base of understanding for
the requirements model. The analysis process is iterative but requirements and analysis
models should be stable before moving on to subsequent models
Design and Implementation Phases – The implementation environment must be

identified for the design model. This includes factors such as DBMS, distribution of
process, and constraints due to programming language, available component libraries, and
incorporation of GUI tools etc. The analysis objects are translated into design objects that
fit the current implementation environment
Testing phase – There are many testing types – unit testing, integration testing, system
testing etc.
4. Design Patterns – An Overview
Patterns for Software Development - An emerging idea in systems development is that

the process can be improved significantly if a system can be analyzed, designed, and built

from prefabricated and predefined system components. There are commonly encountered
and difficult problems that are recurring and repetitive and hence a need arises for a
standard vocabulary for communicating insight and experience about these problems and
their solutions. This enforces the view of having a body of literature consisting of both the
identified problems and solutions to help software analysts, architects, and developers.
Thus the focus here is on inculcating the culture of document creation in order to support
sound engineering architecture, design, best practices, guidelines etc. as the documentation
immensely helps to categorize and communicate about solutions to recurring problems.
The pattern has a name to facilitate discussion, and the information it represents. The
documentation of a pattern, in essence, provides the contexts under which it is suitable and
the constraints and forces that may affect a solution or its consequences.
Communication about patterns is enabled by a vocabulary that describes the pattern and its
related components such as name, context, motivation, and solution. By classifying these
components and their nature such as the structural or behavioral nature of the solution, we
can categorize patterns. The concept of patterns and their documentation is becoming
popular among the software professionals. They are being extensively used for shortening
the development time and to enhance the quality of software solutions. The OO thinkers
have come out with the roles of design patterns. They could identify the key aspects of a
common design structure that make it useful for creating a reusable OO design. Further
more, design patterns identify the participating classes and instances, their roles, and
collaborations and the distribution of responsibilities. Patterns also describe whet they can
be applied, whether they can be applied in view of other design constraints, and the
consequences and trade-offs of their use.
Patterns and pattern languages should be able to generate whole, living structures. Part of
the desire to create architectures emulating life lies in the unique ability of living things to
evolve and adapt to their ever-changing environments. Similarly, a good software
architecture is about being adaptable and resilient to change. The successive application of
several patterns, each encapsulating its own problem and forces, unfolds a larger solution,
which emerges indirectly as a result of the smaller solutions.
Pattern Types - A pattern in waiting, which is not yet known to recur, is called a proto-
pattern. Generative patterns are patterns that not only describe a recurring problem, they
can tell us how to generate something and can be observed in the recurring system
architectures they helped shape. Non-generative patterns are static and passive. They
describe recurring phenomena without necessarily saying how to reproduce them. We

have to document generative patterns due to their significant contributions for efficient
software development.
Pattern Application Domains - Patterns are being largely used for software architecture
and design and more recently, for all aspects of software engineering, including
development organization, the software development process, project planning,
requirements engineering, and software configuration management. A good pattern will
do the following:
 It solves a problem. Patterns capture solutions, not just abstract principles or

strategies
 It is a proven concept. Patterns capture solutions with a track record, not theories
or speculation
 The solution is not obvious. The best patterns generate a solution to a problem
indirectly
 It describes a relationship. Patterns do not just describe modules, but describe

deeper system structures and mechanisms
 The pattern has a significant human component. All software serves human
comfort or quality of life; the best patterns explicitly appeal to aesthetics and
utility.
 A good pattern description should fully encapsulate all the forces that have an
impact on it
Pattern Templates - Each pattern must be expressed in the form of a rule (template),
which establishes a relationship between a context, a system of forces which arises
in that context, and a configuration, which allows these forces to resolve themselves
in that context. A pattern should contain certain essential components:
1. Name – Every pattern should contain a meaningful name,

which may be a single word or short phrase to refer to the pattern and the
knowledge and structure it describes.

2. Problem – A statement of the problem that describes its

intent: the goals and objectives it wants to reach within the given context and
forces.
3. Context – The preconditions under which the problem and

its solution seem to recur and for which the solution is desirable. It can be thought
of as the initial configuration of the system before the pattern is applied to it.
4. Forces – A description of the relevant forces and constraints

and how they interact or conflict with one another and with the goals we wish to
achieve. Forces reveal the intricacies of a problem and define the kinds of trade-
offs that must be considered in the presence of the tension or dissonance they
create.
5. Solution – Static relationships and dynamic rules describe

how to realize the desired outcome. This often is equivalent to giving instructions
that describe how to construct the necessary products. The description may
encompass pictures, diagrams, and prose that identify the pattern’s structure, its
participants, and their collaborations, to show how the problem is solved. The
solution should describe not only the static structure but also the dynamic
behavior. The static structure tells us the form and organization of the pattern but
the behavioral dynamics is what makes the pattern “come alive”.
6. Examples – One or more sample applications of the pattern

that illustrate a specific initial context; how the pattern is applied to and transforms
that context and the resulting context left in its wake. Examples help the reader to
understand the pattern’s use and applicability. Visual examples and analogies often
can be very useful.
7. Resulting Context – The state or configuration of the system

after the pattern is applied, including the consequences (both bad and good) of
applying the pattern, and other problems and patterns that may arise from the new
context. It describes the post conditions and side effects of the pattern. This is
sometimes called a resolution of forces because it describes which forces have
been resolved, which ones remain unsolved, and which patterns may now be
applicable. Documenting the resulting context produced by one pattern helps to
correlate it with the initial context of other patters.

8. Rationale – A justifying explanation of steps or rules in the

pattern and also of the pattern as a whole in terms of how and why it resolves its
forces in a particular way to be in alignment with desired goals, principles and
philosophies. It explains how the forces and constraints are orchestrated in concert
to achieve a resonant harmony. That is, how the pattern actually works, why it
works, and why it is good
9. Related patterns share the common forces. They also have

an initial or resulting context that is compatible with the resulting or initial context
of another pattern. Such patterns might be predecessor patterns whose application
leads to this pattern, successor patterns whose application follows from this
pattern, alternative patterns that describe a different solution to the same problem
but under different forces and constraints, and codependent patterns that may be
applied simultaneously with this pattern.
10. Known Uses – The known occurrences and its applications

within existing systems need to be documented. This helps validate a pattern by
verifying that it indeed is a proven solution to a recurring problem.
Antipatterns – A pattern represents a best practice whereas an antipattern represents

worst practice or a lesson learned. Antipatterns come in two varieties:
 Those describing a bad solution to a problem that resulted in a bad

situation
 Those describing how to get out of a bad situation and how to proceed
from there to a good solution
Antipatterns are valuable as it helps to understand good solutions by seeing and

understanding bad solutions.
Capturing Patterns – A pattern should help its users to comprehend existing systems,
customize systems to fit user needs, and construct new systems. The process of looking for
patterns to document is called pattern mining. The following guidelines give what exactly
is a pattern.
 Focus on practicality – Patterns should describe proven solutions to recurring

problems

 Aggressive disregard of originality – Pattern writers do not need to be the original

inventor or discoverer of the solutions that they document
 Nonanonymous review – Pattern submissions are shepherded rather than reviewed.

The shepherd contacts the pattern authors and discusses with him or her how the
patterns might be clarified or improved on
 Writers’ workshops instead of presentations – Rather than being presented by the

individual authors, the patterns are discussed in writers’ workshops, open forums,
and mini conferences
 Careful editing – The pattern authors should have the opportunity to incorporate all
the comments and insights during the shepherding and writers’ workshops before
presenting the patterns in their finished form.
5. Frameworks
A framework is a set of cooperating classes that make up a reusable design for a specific
class of software. A framework provides architectural guidance by partitioning the design
into abstract classes and defining their responsibilities and collaborations. A developer
customizes a framework to a particular application by sub classing the composing
instances of framework classes. The framework captures the design decisions that are
common to its application domain. Frameworks thus emphasize design reuse over code
reuse, though a framework will usually include concrete subclasses we can put to work
immediately. Thus a framework is a way of presenting a generic solution to a problem that
can be applied to all levels in a development. Design and software frameworks are
currently popular.
Why Frameworks? - Frameworks are a way of delivering application development

patterns to support best practice sharing during application development. The motivations
for frameworks are as follows. An experienced programmer almost never codes a new
program from scratch. He will use macros, copy libraries, and template-like code
fragments from earlier programs to make a short on a new one. Work on the new program
begins by filling in new domain-specific code inside the older structures
A seasoned business consultant who has worked on many consulting projects performing
data modeling almost never builds a new data model from scratch. Instead, he will make

use of model fragments that have been developed over time to help new modeling projects
hit the ground running.
Design Patterns Vs Frameworks - A single framework typically encompasses several

design patterns. In fact, a framework can be viewed as the implementation of a
system of design patterns. A framework is executable software, where design
patterns represent knowledge and experience about software. Frameworks are in a
way of a physical nature, while patterns are of a logical nature: Frameworks are the
physical realization of one or more software pattern solutions; patterns are the
instructions for how to implement those solutions
 Design patterns are more abstract than frameworks – Frameworks can be

embodied in code, but only examples of patterns can be embodied in code.
Frameworks are written using a programming language and reused directly. In
contrast, design patterns have to be implemented each time they are used. Design
patterns also explain the intent, trade-offs, and consequences of the design
 Design patterns are smaller architectural elements than frameworks – A typical

framework contains several design patterns but the reverse is never true
 Design patterns are less specialized than frameworks – Frameworks always have a
particular application domain. In contrast, design patterns can be used in nearly
any kind of application.
6. Unified Approach (UA)
This approach is based on the best practices that have proven successful in system
development and more specifically the work done by the stalwarts of OO paradigm. The
UA establishes a unifying and unitary framework around their works by utilizing the UML
to describe, model, and document the software development process. The main idea
behind this UA is to combine the best practices, processes, methodologies, and guidelines
along with UML notations and diagrams for better understanding OO concepts and
systems development. The UA revolves around the following processes
 Use case driven development
 Object-oriented analysis
 Object-oriented design

 Incremental development and prototyping
 Continuous testing
The methods and technology employed include
 UML used for modeling
 Layered approach for software development
 Repository for OO system development containing best practices, patterns and

frameworks
 Component-based development
The UA allows iterative development by allowing to go back and forth between the design
and modeling or analysis phases.
OOA – Analysis is the process of extracting the needs of a system and what the system
must do to satisfy the user requirements. The goal is to understand the domain of the
problem and the system’s responsibilities by understanding how the users or will use the
system. This is accomplishing by constructing several models of the system. The models
concentrate on describing what the system does rather than how it does it. Separating the
behavior of a system from the way it is implemented requires viewing the system from the
user’s perspective rather than that of the machine.
OOA process consists of the following steps:
1. Identify the Actors
2. Develop a simple business process model using UML

Activity diagram
3. Develop the Use Case
4. Develop interaction diagrams
5. Identify classes
OOD – The UA utilizes Jacobson’s analysis and interaction diagrams, Booch’s object
diagrams and Rumbaugh’s domain model. Further more, by following Jacobson’s life

cycle model, we can produce designs that are traceable across requirements, analysis,
design, coding, and testing. OOD process consists of:
1. Designing classes, their attributes, methods, associations, structures, and protocols,

apply design axioms
3. Design and prototype user interface
4. User satisfaction and usability tests based on the usage / use cases
5. Iterate and refine the design
Iterative Development and Continuous Testing – We must iterate and reiterate till we
are satisfied with the system. Since testing often uncovers design weaknesses, we need to
repeat the entire process, taking what we have learned and reworking our design or
moving on to reprototyping and retesting. During this iterative process, our prototypes will
be incrementally transformed into the actual application. The UA encourages the
integration of testing plans from day 1 of the project. Usage scenarios can be test scenarios
and use cases will drive the usability testing.
Unified Modeling Language (UML) – The UML merges the best of the notations used
by the three most popular analysis and design methodologies. UML is becoming the
universal for modeling OO systems. It is to express models of many different kinds and
purposes just as a programming language is used in different ways. The UA uses the UML
to describe and model the analysis and design phases of systems development.
7. The Layered Approach to Software Development
Most systems being developed today are two-layered architecture: interface and data. The
three-layered approach consists of a view or user interface, a business layer and an access
layer. The business layer contains all the objects that represent the business (both data and
behavior). This is where, the real objects such as Order, customer, inventory and invoice
exist. The responsibilities of business layer are: model the objects of the business and how
they interact to accomplish the business processes. These objects should not be responsible
for the following:
1. Displaying details – Business objects should have no special knowledge of

how they are being displayed and by whom. They are designed to be

independent of any particular interface so the details of how to display an

object should exist in the interface (view) layer of the object displaying it
2. Data access details – Business objects also should have no special knowledge
of data and its origin. It does not matter to the business model whether the data
are stored and retrieved via SQL or file I/O. The business objects need to know
only to whom to talk about being stored or retrieved.
A business model captures the static and dynamic relationships among a collection of
business objects. Static relationships include object associations and aggregations. For
example, a customer could have more than one account or an order could be aggregated
from one or more line items. Dynamic relationships show how the business objects
interact to perform tasks. For example, an order interacts with inventory to determine
product availability. An individual business object can appear in different business
models. Business models also incorporate control objects that direct their processes.
The user interface (View) layer – The UI layer consists of objects with which the user
interacts as well as the objects needed to manage or control the interface.
1. Responding to user interaction – The UI layer objects must be designed to

translate actions by the user, such as clicking on a button or selecting from a menu,
into an appropriate response. That response may be to open or close another
interface to send a message down into the business layer to start some business
process.
2. Displaying business objects - This layer must paint the best possible picture of the
business objects for the user. In one interface, this may mean entry fields and list
boxes to display an order and its items. In another, it may be a graph of the total
price of a customer’s orders.
The Access layer contains objects that know how to communicate with the place where
the data actually reside, whether it is a relational database, OODBMS. Regardless of
where the data actually reside, the objectives
1. Translate request – this layer must be able to translate any data-related requests
from the business layer into the appropriate protocol for data access. For example,

if customer number 55552 needs to retrieved, the access layer must be able to
create the correct SQL statement and execute it
2. Translate results – This layer also must be able to translate the data retrieved back
into the appropriate business objects and pass those objects back up into the
business layer.
8. The UA Repository
In modern businesses, best practice sharing is a way to ensure that solutions to process and
organization problems in one part of the business are communicated to other parts where
similar problem occur. Best practice sharing eliminates duplication of problem solving.
For many companies, best practice sharing is institutionalized as part of their constant goal
of quality improvement. Best practice sharing must be applied to application development
if quality and productivity are to be added to component reuse benefits.
The idea promoted here is to create a repository that allows the maximum reuse of
previous experiences, knowledge gathered and previously defined specifications, objects,
principles, practices, processes, procedures, software modules, classes, components,
services, and applications in an easily accessible manner with a completely available and
easily utilized format. Everything from the original user request to maintenance of the
project as it goes to production should be kept in the repository. The advantages of
repositories are many. If we store software objects from our projects implementations for
our clients in the repository, they can be reused for forthcoming projects. Any thing such
as the definition of data element, diagrams symbols, definitions, etc can be stored in the
repository. Thus software development becomes easier, and quicker. If new requirements
emerge, new objects will be design and stored in the main repository for future use. The
repository will be made available and accessible for many. Also there are UML diagrams,
design patterns, frameworks, CASE tools, IDEs etc that also facilitate quicker software
development.
The Rational Objectory Process is an object-oriented process developed by Booch,

Jacobson, and Rumbasugh. This process is structured along two dimensions: Process and
Time. The phases involved in each dimension are described below:
Time Dimension:

• Inception – In the inception phase the scope and rational for the project are
determined. Economic, organizational, political and technical issues are considered.
In determining the scope of the project, all persons/organizations/items that interact
with the system are identified, and the nature of the interactions is determined. At the
end of this phase, the objectives of the project are examined (taking into account the
issues examined during this phase), and a decision is make whether or not to proceed
with the project.
• Elaboration – In the Elaboration Phase, the problem is examined in greater depth, and
issues of what to build, how to build it, and what technologies to use are considered.
The requirement, technical, skill, and political risks are accessed. “Use cases” are used
improve the communication between sponsors and developers, thus reducing the
requirement risks. Technical risks are mitigated by the use of prototypes. The
elaboration stage should result in a list of use case detailing the requirements, and a
domain model that captures the developers understanding of the business.
• Construction Phase – The construction phase involves a series of iterations that

builds the system. Analysis, design, coding, testing, and integration is done on the use
cases for each iteration. Iteration involves identifying the classes and relationship to
be build, completing the design for the classes and relationships, creating/updating
project documents, testing the iterations, and then integrating it with any previous
iterations. At the end of the iterations the product is shown to the user, and examined
to determine if the use cases have been correctly built.
• Transition Phase – In this phase, the software product is deployed into the user
community. Starting with a Beta release, user feedback is used to identify and fix
problems with the product. After the beta period, a general release of the product is
performed.
Process Dimension:
• Requirements Process – The requirements model is built during this process, in order
to determine what the system should do. Expanded use cases, use case diagrams, flow
of events, and requirement reviews are all tools uses in this process. An expanded use
case identifies the actors involved in the use case, the purpose and type of use case,
lists any cross references with system functions, and describes ( in detail ) how the
system interacts with the relevant actors using a flow of events ( scenario ). The flow

of events in a use case should include information on when and how the use case
starts, what interactions the use case has with the actors, what data is needed by the use
case, the normal sequence of events in the use case and a description of any alternate
flows.
• Analysis Process – The use cases from the requirements process are examined and
used in the creation of a list of candidate classes. In this phase, a conceptual model of
the system is built. A conceptual model may display the classes, the associations that
exist between the classes, and the class attributes. Sequence diagrams and state
transition diagrams can be used to assist in identifying the system’s behavior.
• Design Process – The definitions of the classes ( class diagrams ) and system
architecture are developed during the design process. A project plan is developed that
schedules the iterations for the implementation stage, and identifies/priorities the
major risks.
• Implementation Process– The software is built ( coded ) during this process.
• Testing Process – The software is tested during this process. Use cases and sequence
diagrams can be useful tools in verifying the system meets the user requirements.
Critique:
The object oriented approach to software development has become extremely popular as
of late. The idea is that using objects allows developers to create a system architecture
that more closely matches the real world situation. Object oriented (OO) also promotes
the concept of reuse, as inheritance can make this an easier task. However much of these
advantages of object oriented development also depend on the skill and inclination of the
developers involved in a project. For example, a developer that is unfamiliar with the OO
methodology could write a OO program that makes little use of inheritance, and reuse.
Similarly a skilled developer could use reuse in a structured project.
In terms of requirements elicitation, I think that Use Cases and Sequence diagrams would
be effective tools in gaining a shared understanding of the system with users. Use Cases
describe actual events that would occur when the users ( actors ) interact with the system.
Sequence diagrams provide a graphical display of these user/system interactions. Since
either technique details events based on the users actual working environment, the users

would be able to provide valuable feedback on whether or not the proposed system will
meet their requirements.
Comparison with other Techniques:
In comparing the object oriented approach to structured analysis and design (as this is the
topic I am presenting), my impression is that the object oriented approach has better tools
for requirements elicitation and confirmation than the traditional structured approach has.
This may be due to the fact that OO is a more recent technique, and thus has been shaped
by current knowledge of the importance of the requirements process. However, the OO
techniques for requirements elicitation ( use cases and sequence diagrams ) could
effectively be used during the requirements stage of a structured project.
In terms of CASE tools, the popularity of OO has resulted in a wide selection of OO

tools. While attempting to find structured CASE tools on the Internet ( for my
presentation ), I found numerous links to OO CASE tools, but only a few select links to
structured CASE tools.
Exercises:
System Definition: Point of Sale ( POS ) system
Overview Statement: Using the object-oriented approach, develop a POS terminal system
that can be used in retail.
System Actors: Cashiers, Customers, Manager
System Functions:
• The system shall allow a cashier to enter an item’s product code.
• The system shall allow the cashier to override the price of an item if the manager
enters an override code.
• The system shall allow the cashier to enter the price of an item that does not have a
product code.
• The system shall record the items purchased on a sale, and calculate a total ( including
tax ).
• The system shall print a receipt on a sale, detailing the items purchased and the total.
• The system shall allow the customer to pay by cash, debit card, credit card or check.

• The system shall get authorization for all debit card, credit card or check payments
before proceeding with the sale.
• The system will only allow access to individuals with a valid security code.
• The system shall allow the cashier to correct mistakes in a transaction.
Expanded use case and flow of events for “Buy Item”:
Use Case Buy Items

Actors Customers, Cashier
Type Primary
Customer arrives at checkout with items
A cashier record purchase items and shows the customer the total.
Description
Customer selects payment method and pays
Cashier accepts payment and gives the Customer the receipt.
POS Conceptual model:

POS Sequence Diagram:
Introducing UML: Object-Oriented Analysis and Design
The purpose of UML, or Unified Modeling Language, is communication; to be specific, it

is to provide a comprehensive notation for communicating the requirements, architecture,
implementation, deployment, and states of a system. This article will offer an overview of
Object Oriented Analysis and Design, focusing in on the three most important concepts it
encompasses: objects, analysis, and design. It is excerpted from the book UML Applied: A
.Net Perspective, by Martin Shoemaker
IN UML, the L is for language, one of the definitions of which is “any means of
communicating,” according to the Merriam-Webster Dictionary. That is the single
overriding purpose of UML, or the Unified Modeling Language: to provide a
comprehensive notation for communicating the requirements, architecture,
implementation, deployment, and states of a system.
UML communicates these aspects from the particular perspective of Object Orientation
(OO), in which everything is described in terms of objects: the actions that objects take,

the relationships between the objects, the deployment of the objects, and the way the states
of the objects change in response to external events.
The starting point in this chapter will be an overview of Object-Oriented Analysis and
Design (OOAD), focusing in on the three most important concepts it encompasses—
objects, analysis, design—because to understand UML, you first must understand these
broader concepts. If you’ve programmed with any OO language, then you’re probably
already familiar with a lot of these ideas, so I’ll keep this discussion brief. Besides, a full
discussion of OOAD is beyond the scope of this book. If you want to explore OOAD
further, you should read Booch’s Object-Oriented Analysis and Design with Applications.1
Next, I’ll discuss the results of the OOAD process, namely, a model. I’ll take a bit of a
diversion to discuss the nature of models, how you use them, and why they’re important.
For the rest of the chapter, I’ll be focusing on UML, looking at what it is, and— perhaps
more importantly—what it isn’t. But before I get started into the nitty gritty of all the
different UML elements and diagrams and what the notation looks like (I’ll save that for
the next chapter!), I’ll be showing you some UML diagrams from the case study that I’ll
be developing in detail in the next part of the book. Now these diagrams aren’t there to
scare you off: quite the contrary. When you start to look at some real-world UML, you’ll
see how intuitive it is, and how you can understand much of it without any formal
teaching.
Objects
Many modern programming languages depend largely or exclusively on the concept of

objects: a close syntactic binding of data to the operations that can be performed upon that
data. In these Object-Oriented languages—C++, C#, Java, Eiffel, Smalltalk, Visual
Basic .NET, Perl, and many others—programmers create classes, each of which defines
the behavior and structure of a number of similar objects. Then they write code that
creates and manipulates objects that are instances of those classes.
One reason why objects are a powerful programming technique—the reason most often
touted in the early literature on Object-Oriented Programming— is that programmatic
objects map naturally to real-world objects. Suppose, for example, that your company has
to deal with orders. These orders would probably have an ID number and contain

information on products. You could create Order objects, which would map to these real-
world objects, and which would have properties such as ID and ProductList. You’d
probably want to be able to add a product to the order and to submit the order, so you
could write AddProduct and SubmitOrder methods. This mapping between objects in
the real world and more abstract code objects encourages programmers to think in the
problem domain, rather than in computer science terms. This benefit has perhaps been
overstated, however; unless you’re building a simulator of a real-world process, such
surrogate “real-world” objects form just the surface of your system. The complexity of
your design lies underneath that surface, in code that reflects business rules, resource
allocation, algorithms, and other computer science concerns. If you only use objects to
reflect the real world, you leave yourself with a lot of work.
A more important benefit of classes and objects is that they form a nice syntactic
mechanism for achieving some classic aspects of well-designed code:2
Encapsulation. The goal of encapsulation is to expose only enough of a module or

subsystem to allow other modules to make use of it. Object-Oriented Programming allows
you to specify the degree of visibility of elements of your code, so that client code is
restricted in what it can access. Thus, you can syntactically seal off implementation
details, leading to more flexibility and maintainability in your system.
Loose coupling. Coupling refers to the ways in which and degrees to which one part of
the system relies on the details of another part. The tighter the coupling, the more changes
in one part of the system will ripple throughout the system. With loose coupling, the
interfaces between subsystems are well defined and restricted. What lies beyond those
interfaces can change without any changes needed in the client sub systems. Object-
Oriented Programming supports loose coupling by allowing you to define and publish a
class’s methods without publishing how those methods are carried out. This principle goes
even further in OO languages that support interfaces (described later in this section).
Strong cohesion. Cohesion refers to the degree in which elements within a subsystem
form a single, unified concept, with no excess elements. Where there is high cohesion,
there is easier comprehension and thus more reliable code. Object-Oriented Programming
supports strong cohesion by allowing you to design classes in which the data and the
functions that operate on them are tightly bound together.

Does OO force you to have these quality attributes in your code? I wish! No matter the
language, you can write shoddy code with no encapsulation, pathological coupling, and no
cohesion. Furthermore, some OO languages are less rigid than others in how much they
require you to design around objects. But OO languages certainly support these quality
attributes if you take the time to pursue them.
The key concepts in Object-Oriented Programming are these:
Classes. A class is the definition of the behavior and properties of one or more objects
within your system. A class binds the data (attributes) of an object to the behavior
Attributes. An attribute is a data value or state that describes an object and helps you to
tell one object from another of the same class. It seems that every new OO language
author feels the need to distinguish their language by coming up with new terminology. In
some OO languages, these data values are called properties or member variables or
member data; but in UML, the proper term is attributes.
Operations. An operation is a behavior or function that an object can perform. Depending

on the OO language, these might be called methods or member functions or even
messages. The last term, messages, comes from Smalltalk, one of the earliest OO
languages, in which all objects communicated by sending messages to each other. You’ll
see a similar use of the term message when we study Sequence Diagrams.
Objects. An object is an instance or specific example of a class. If Dog is the class, then
Betsy, Ladi, Patches, Jake, Radar, and Frosty are specific instances of the class found in
my house. The attributes of the class have specific values within an object of that class;
and the operations of a class operate on the attributes of individual objects.
Inheritance. This concept indicates that one class (the superclass) provides some common
or general behavior inherited by one or more specific classes (the subclasses). The
subclasses then provide more or different behavior beyond that defined in the superclass.
For example, besides the Dogs, I have Cat objects and Horse objects that live on my
property. Each class has unique behaviors: Dogs must be walked, Cats use the litter box,
and Horses drop manure that must be scooped up and thrown in the manure pile. Yet all

classes have some common behavior: they must be fed, and they must have vet visits. So I
can define a superclass, Pet, and have my subclasses, Dog, Cat, and Horse, derive their
shared behavior from the Pet class. In UML, this concept is known under the slightly
different term of generalization, in which a superclass provides the generalized behavior
of the subclasses. It’s really the same concept, but just looking at it the other way up.
Components. A component is a collection of related classes that together provide a larger

set of services. Components in your system might include applications, libraries, ActiveX
controls, JavaBeans, daemons, and services. In the .NET environment, most of your
projects will require component development.
Interfaces. An interface is a definition of a set of services provided by a component or by

Each of these concepts will be explored in more detail as I discuss the UML diagrams that
represent them.
In software development, analysis is the process of studying and defining the problem to
be resolved. (We all define the problem before we start solving it, right? Right? Oh,
please, somebody say “Right!” We can’t all be that screwed up, can we?) It involves
discovering the requirements that the system must perform, the underlying assumptions
with which it must fit, and the criteria by which it will be judged a success or failure.
Object-Oriented Analysis (OOA), then, is the process of defining the problem in terms of
objects: real-world objects with which the system must interact, and candidate software
objects used to explore various solution alternatives. The natural fit of programming
objects to real-world objects has a big impact here: you can define all of your real-world
objects in terms of their classes, attributes, and operations.
Design
If analysis means defining the problem, then design is the process of defining the solution.
It involves defining the ways in which the system satisfies each of the requirements
identified during analysis.

Object-Oriented Design (OOD), then, is the process of defining the components,

interfaces, objects, classes, attributes, and operations that will satisfy the requirements.
You typically start with the candidate objects defined during analysis, but add much more
rigor to their definitions. Then you add or change objects as needed to refine a solution. In
large systems, design usually occurs at two scales: architectural design, defining the
components from which the system is composed; and component design, defining the
classes and interfaces within a component.
Models
Did you ever build a model ship? When I was young, my mom and I built a model of the
famous clipper ship Cutty Sark.3 I’ve always been fascinated by the tall ships of old; but I
really learned about how they work when we built that model. All of the strange nautical
terminology from the old pirate movies—forecastle, capstan, main mast, and especially
belaying pins (“You mean they’re not just there so somebody can pull one out and swing it
as a club?”) — gained concrete meaning when I assembled them and saw them in the
context of the entire system.
Well, that’s a central goal of using UML in OOAD: to let you study and understand a
system via a model of that system. Like aerodynamic engineers, construction architects,
and others in the physical engineering world, you’ll build models of systems yet to be
built, not just models of existing systems. Your models will let you explore design
alternatives and test your understanding of the system at a much faster rate and much
lower cost than the rate and cost associated with actually building the system.
“But wait a minute!” the skeptic in the crowd shouts. “I can see the Cutty Sark, if I travel
to London. And I can see the model Cutty Sark, if I visit your home. I can look at the two,
and see how the model relates to the real thing. But I can’t ‘look at’ software, except at its
user interface. So your model looks like the UI? Isn’t that just a prototype?” That’s the
problem with the usual engineering model analogy as applied to software models: there’s
no direct physical correspondence between the model and the final product. A better
analogy is to models in less tangible scientific disciplines. Quantum physics is a good
example of a field in which models help you to understand things you can’t see: no one
can see quarks or leptons or hadrons or any of the many subatomic particles; and attributes
like charm and strangeness have only metaphorical meaning. The models of quantum

physics aren’t literally true, yet they’re very useful in understanding physical phenomena.
Software models are like that: useful metaphors and abstractions to help you think about a
problem and a solution, not literal depictions of the code itself.
In the case of OOAD with UML, your models consist primarily of diagrams: static
diagrams that depict the structure of the system, and dynamic diagrams that depict the
behavior of the system. With the dynamic diagrams, you can trace through the behavior
and analyze how various scenarios play out. With the static diagrams, you can ensure that
each component or class has access to the interfaces and information that it needs to carry
out its responsibilities. And it’s very easy to make changes in these models: adding or
moving or deleting a line takes moments; and reviewing the change in a diagram takes
minutes. Contrast that with actually building the code: hours to implement the change,
hours more to test and review it.
But remember The Model Rule:
To use UML effectively, you should never be simply drawing pretty pictures; you should
always be editing an underlying model, using the pretty pictures as your user interface.
Your core artifact of the OOAD process is the model. In fact, you will likely have multiple
models:
• Analysis Model. This is a model of the existing system, the end user’s
requirements, and a high-level understanding of a possible solution to those
requirements.
• Architecture Model. This is an evolving model of the structure of the solution to

the requirements defined in the Analysis Model. Its primary focus is on the
architecture: the components, interfaces, and structure of the solution; the
deployment of that structure across nodes; and the trade-offs and decisions that led
up to that structure.
• Component (Design) Models. This is a number of models (roughly, one per

component) that depict the internal structure of the pieces of the Architecture
Model. Each Component Model focuses on the detailed class structure of its
component, and allows the design team to precisely specify the attributes,
operations, dependencies, and behaviors of its classes.

Depending on your development process, you may have even more models: a Business
Model, a Domain Model, possibly others. The major benefit of models is that you can
make model changes far earlier in the development cycle than you can make code changes,
and far easier. And because you can make changes early, you can make your mistakes
early. And that’s a good thing, because early detection and correction is cheap detection
and correction. Modeling will let you catch your most costly bugs early; and early
detection and correction can save you a factor of 50 to 200 on the cost and schedule of a
bug fix.4
Equal Time for an Extreme Perspective
Although software engineering literature is rife with research that demonstrates that the
cost to fix a defect rises catastrophically over time, those in the Extreme Programming
camp disagree. They argue that all such research is dated, and that modern development
tools and techniques allow a maximum limit to the cost of change.5 They see not an
exponential growth, but an asymptotic approach, as shown in Figure 1-1.
Figure 1-1. Cost to correct defects over time

To which theory I can only reply, “So?”
• First, their theory is a prediction, not a guarantee: if you apply the techniques they
advocate and if you do everything correctly and if you are working in the right sort
of environment on the right sort of project, then the lessons of 30 years of software
engineering will allow you to attain the asymptotic curve. Good for you, if you can
do that; but the exponential curve is the default behavior. (Furthermore, I would
argue that modeling is a useful tool for attaining that asymptotic curve.)
• Second, look at those curves. Do you want to argue over which curve is “right” at
the 8-weeks mark? Or would you rather just fix the problem at the 1-week mark?
(Beck argues that there is benefit in waiting for the latest possible time, so that you
have the maximum information when you make the fix and also so that you don’t
waste time fixing problems that never really arise; but his actual example shows
the benefits of making a change as soon as you are aware of it. These concerns
aren’t incompatible.)
Modeling has another benefit, one I call The Outline Effect. Back in high school, I never
needed study habits: I liked to read, and I liked to learn, so school came easy to me at my
small rural high school. Then I went to a Big Ten university, and reality came crashing in
on me. I didn’t understand that learning at that level was supposed to be work, a job you
tackled in a systematic fashion with specific goals and strategies. My “strategy” was sort
of like code-and-fix: just tackle whatever came along, and hope it all worked out. It didn’t,
and I didn’t understand why. Every night, I sat in my room, reading the textbooks . . until
something distracted me, which happened far too often. Meanwhile, every night, a friend
sat in his room across the hall, outlining the textbooks. And surprise—he had a much
better GPA than I did.
It took me years to appreciate my friend’s study skills. The process of outlining the text
forced him to focus: he had a concrete goal in mind, and wouldn’t allow distractions until
he finished it. Furthermore, the outlining involved more of his brain: in order to produce
an outline of the textbook, he first had to comprehend the textbook; and then to actually
write the outline in his own words, he had to involve yet more areas of his brain, as he had
to formulate what he wanted to write. Heck, he even had to involve his tactile and motor

areas of his brain in order to write the words. He had a much more fully involved brain,
and thus he much more fully understood the material.
This is a benefit you can gain from modeling: by listening and talking and reading and by
then translating what you learn into a model, you learn it more thoroughly. This is even
more important in system design than in studying from a textbook: in a textbook, you
expect that the text will be more or less consistent, and that any seeming inconsistency is
most likely a sign of something you misunderstood; but in requirements gathering,
contradiction and inconsistency are inevitable parts of the process. By modeling the
requirements, you may highlight the inconsistencies, particularly when you gather details
from many different parts of a specification and put them together in the same diagram.
And there’s one more modeling benefit, one I believe I may have mentioned earlier:
communication. It’s easier to communicate with models than with text, or even with code;
and you can communicate with a wider audience with models than with other forms of
expression. Once you’ve created a diagram “in your own words,” I can more easily
comprehend how you comprehend things by comparing your diagram with what I
comprehend.
UML, the Unified Modeling Language, is a graphical language designed to capture the
artifacts of an OOAD process. It provides a comprehensive notation for communicating
the requirements, behavior, architecture, and realization of an Object-Oriented design. As
you saw in the last section, UML provides you with a way to create and document a model
of a system.
What Makes the UML Unified?
To answer that, you need to jump in the WayBack Machine and travel back to the ancient
history of OOAD—say, 1995. At that time, Object-Oriented Programming had proven its
worth as a way of building applications and systems; and the hot new topics in the OO
world were OOA and OOD. Since these topics were larger in scope than mere
programming, the practitioners needed a way of displaying large, complex concepts in a
simple graphical fashion. A number of competing OO notations emerged, chief among
them being the Booch Notation designed by Grady Booch and the Object Modeling
Technique (OMT) designed by James Rumbaugh (and others). And then began the

religious wars: fanatical adherents of the competing notations fought petty little battles
over clouds (Booch’s symbol for a class) versus rectangles (OMT’s symbol for a class).
Booch and Rumbaugh looked on this confusion with dismay: they saw the differences
between their notations as minor, unworthy of so much rancor. And worse, they saw the
religious wars detracting from what they felt should be the new focus: the OOAD process
itself, particularly as a means for capturing requirements and behavior. They were very
impressed by some of Ivar Jacobson’s work on Sequence Diagrams and his Objectory
methodology; but with all the shouting about notation, no one was talking about process.
So Booch and Rumbaugh and Jacobson (the Three Amigos) went on retreat to hammer out
differences in their notations in private, and to adopt other useful notations as well (chief
among these being David Harel’s State Diagram notation). They emerged with the Unified
Modeling Language 0.8, a response to the Object Management Group’s call for a standard
object modeling notation; and Booch’s company, Rational6 (which had hired Rumbaugh
and Jacobson) incorporated UML into Rational ROSE, their OOAD tool. The UML then
went through a few cycles of response and revision by the OO community; and UML 1.1
was adopted as a standard by the OMG in 1997. UML has been further refined, and is
currently at version 1.4, with version 2.0 on the near horizon.
What UML Isn’t
With so much in UML, it’s worth mentioning what’s not UML. The following sections
describe some related concepts that are often confused with UML itself.
A Process
Remember the goal of the Three Amigos: to focus attention on the OOAD process, not on
the notation. Their notation isn’t a process in itself; rather, it’s designed to support a wide
range of OO processes. There are a number of UML-based OOAD processes, including
Fowler’s outline process,7 controlled iteration,8 Texel and Williams’s complete OO
process,9 and, of course, the Unified Process (formerly Objectory) from the Three
Amigos.10 A full list would be much longer, but would have a lot in common with these
prominent examples. These processes differ somewhat in the degree of formality and the
order of operations; but all involve using UML to identify and refine requirements,
allocate those requirements to functional modules, and refine those modules. Without a

process, new UML students are often adrift in a sea of concepts, with nothing to guide
their course.
In this book, you’ll learn UML within the framework of Five-Step UML, which I find to
be a “just enough” process: just enough process to help you understand the purpose of
UML, but not so much as to bury you in paperwork and obscure the benefits of UML.
Five-Step UML isn’t a large, full-featured OOAD process, falling somewhere between an
academic exercise and Ambler’s Agile Modeling.11 Still, I find that some particularly
process-averse teams that tend to reject a more formal process will accept Five-Step UML.
In the next chapter, I’ll show you how the Five-Step process works, and along the way,
you should pick up a broad working knowledge of UML. In Chapter 3, I’ll talk about
some pragmatic rules I like to apply to the Five-Step (and indeed any other) modeling
process. Throughout the core chapters of this book (Part Two), we’ll work through each of
the five steps in more detail, applying it to a real-world case study. Although the focus of
this book is on Five-Step UML, we will look in more detail at some other processes and
how they work in Chapter 12.
Rational XDE (or Any Other Tool)
Many UML practitioners—and of course, many UML tool vendors—tend to blur the line
between UML and a given tool. I myself am prone to equating “what XDE can do” with
“what UML can do,” since I do most of my UML work with Rational’s XDE tool. This
habit isn’t inherently bad, since it’s usually easier to work with your tools than against
them; but it’s important to realize that the features and capabilities of any given tool—
even the market-leading UML tool from the people who gave us UML—may differ from
the features and capabilities of UML itself. If UML is a language, then every tool speaks
with a unique accent.
You can find a list of available UML tools in Appendix B.
A Silver Bullet
Good code will still require blood, sweat, tears, pizza, good management, and lots of
thought. UML will help you to organize these factors (except the pizza), but you won’t be
able to avoid them.

UML consists of nine different diagram types, each focused on a different way to analyze
and define the system. These diagrams are summarized briefly here:
• Use Case Diagrams show the externally visible behavior of the system. You’ll see
these in the next chapter (Chapter 2) and later on when we look at Step 1 of Five-
Step UML in Chapter 6.
• Activity Diagrams show an elaboration of the behavior of the system. You’ll see
these in the next chapter, and use them during Step 2 of Five- Step UML in
Chapter 7. A recent addition to UML is the division of Activity Diagrams into
swimlanes, which you’ll see in the next chapter, and we’ll use during Step 3 of
Five-Step UML in Chapter 8.
• Component Diagrams show architecture of the system. You’ll see these in the
next chapter, and we’ll use them during Step 4 of Five-Step UML in Chapter 9.
• Sequence Diagrams show object interactions over time. We don’t use these
diagrams as part of Five-Step UML, but we’ll look at them in Chapter 13.
• Collaboration Diagrams show object interactions with emphasis on relations

between objects. We don’t use this type of diagram as part of Five-Step UML, but
we’ll look at them in Chapter 13.
• Class Diagrams show class definition and relations. You’ll see these in the next
chapter, and we’ll use them during Step 5 of Five-Step UML in Chapter 10.
• Statechart Diagrams show state changes in response to events. We don’t use

these diagrams as part of Five-Step UML, but we’ll talk about them in Chapter 13.
• Deployment Diagrams show physical architecture of the system. We’ll use these
in Chapter 11.
• Package Diagrams show the hierarchical structure of your design. These can be
useful for organizing many different types of elements and you’ll be seeing this
type of diagram often throughout the book.
I have a secret. You know those different UML diagram types? Does it annoy you just a
bit, having to learn so many new notations to use UML? Does it make you feel like
skipping OOAD and just jumping into code?

Well, it’s true that making good UML diagrams takes some skill and some practice; but
reading well-crafted diagrams is a very different matter. Just between you and me, I’ll bet
you already know how to read UML diagrams, and you don’t even know it. For the rest of
this chapter, I’m going to show you some examples of the different UML diagrams, and
ask you a few simple questions about what it is they are saying. Don’t worry if you can’t
follow all of the notation at this stage—or indeed if you find the questions too simplistic—
the point of the following exercises is simply to show you how straightforward it is to read
UML diagrams, and how you’ll be able to answer questions about them right away. You
won’t be an expert by any measure—that comes in later chapters—but you’ll be able to
understand the information contained in the diagrams.
Because, see, here’s the secret: UML—it’s all about communication . . .
An Introduction to the Kennel Management System
The exercises and examples in this book all derive from the Kennel Management System
(KMS) for Sandy’s Pets, a high-tech kennel providing temporary and long-term care for
cats, dogs, birds, and exotic pets. The Kennel Management System must provide familiar
features tailored to the pet care domain:
• Reservations and occupancy. Like a good hotel, the KMS must allow pet owners
to reserve kennel space (i.e., “pens”) and to check pets in and out. Unlike a hotel, a
significant fraction of the occupants reside in the kennel long term or even full
time.
• Exercise and grooming schedule. Like a good physical therapy clinic, the KMS
must support and maintain exercise and grooming schedules for each resident.
Unlike a clinic, these schedules are dictated by the pet owner rather than by a
physician or therapist.
• Nutrition and dietetics. Like a good health spa, the KMS must support both
standard and customized diets for each resident. Unlike a health spa, some of the
residents only eat live food.
• Inventory and ordering. Like a good restaurant, the KMS must keep food (and
other supplies) on hand to meet the needs of a varied clientele. Unlike most
restaurants (and as noted previously), some of the food must be stored live.

• Surveillance and tracking. Like a good day care center, the KMS must ensure
that its residents are safe and secure, including allowing the pet owners to view
their pets via Web cams. Unlike day care centers, each resident will be equipped
with a computerized collar or tag, which will allow sensors in the kennel to locate
and check the status of each pet.
• Health care and medication. Like a good health care management system, the
KMS must schedule regular and emergency medical visits, maintain a medical
history, and manage dispensing of medications. Unlike typical health care systems,
the residents come from a wide variety of species and thus need species-specific
medications and treatment programs.
• Customer relations and pedigrees. Like a good contact management system, the
KMS must track information about residents past, present, and possibly future.
Unlike typical contact management systems, the KMS must maintain information
about both a pet’s parentage and future breeding plans.
The KMS must also provide basic human resources, accounting, and administration
functions. For a more detailed specification of the Kennel Management System, see
Appendix A.
Use Case Diagrams
A Use Case Diagram depicts actions by people and systems outside your system, along
with what your system does in response. It’s useful for depicting the functional
requirements of your system. Figure 1-2 shows an example of a simple Use Case Diagram
for the Kennel Management System.

Figure 1-2. Use Case Diagram for care giver requirements
Excercise 101: Reading a Use Case Diagram
Answer the following questions about the diagram:
1. What does the KMS do when the care giver checks a pet in?
2. What does the KMS do when the care giver checks a pet out?
3. What action or actions by the care giver will cause the KMS to update a kennel
assignment?
4. What action or actions by the Care Giver will involve the Veterinarian?
Activity Diagrams
An Activity Diagram depicts the detailed behavior inside a single functional requirement,
including a primary scenario and a number of alternate scenarios. It’s useful for ensuring
that you thoroughly understand a given functionality. Figure 1-3 presents an Activity
Diagram for the one functional requirement of the Kennel Management System for
Sandy’s Pets.

Figure 1-3. Activity Diagram for assigning a pen to a pet
Exercise 102: Reading an Activity Diagram
1. What is the sequence of steps the system performs when assigning a pen to a pet
that has visited previously?
2. What additional steps are performed for a pet that is new to the kennel?
A Component Diagram depicts the deployable units of your system—executables,

components, data stores, among others—and the interfaces through which they interact.
It’s useful for exploring the architecture of your system. Figure 1-4 presents an example of
a Component Diagram for the Kennel Management System.

Figure 1-4. Component Diagram of the Kennel Management System
Exercise 103: Reading a Component Diagram
1. The Care Giver Center is the Web page that the care giver uses to enter
information about a pet. What interface does it use to provide data to the KMS?
2. What other components provide data to the KMS, and through what interfaces?
3. What types of contacts can be made through the Comm Center component?
Sequence Diagrams
A Sequence Diagram depicts the detailed behavior over time within one path or scenario
of a single functional requirement. It’s useful for understanding the flow of messages
between elements of your system. Figure 1-5 presents an example of a Sequence Diagram
for the Kennel Management System.

Figure 1-5. Sequence Diagram for creating a vet record
Exercise 104: Reading a Sequence Diagram
1. Which objects in the system are involved in creating a vet record?
2. Which actors outside the system are involved in creating a vet record?
3. What interface does the Vet Record Page use for creating a vet record?
4. How does the system contact the veterinarian?
Class Diagrams
A Class Diagram depicts the classes and interfaces within the design of your system, as
well as the relations between them. It’s useful for defining the internal, Object-Oriented
structure of your code. Figure 1-6 presents an example Class Diagram from the Kennel
Management System.

Figure 1-6. Class Diagram for Kennel assignment
Exercise 105: Reading a Class Diagram
1. What three classes are associated with the Kennel Assignment class?
2. What operations can objects of the Kennel Assignment class perform?
3. What attributes describe an object of the Pet Record class?
4. What attributes describe an object of the Kennel Space class?
State chart Diagrams
A State chart Diagram depicts how the state of your system changes in response to internal
and external events. It’s useful for ensuring that each event is handled properly no matter
what state your system may be in. Figure 1-7 presents an example of a State chart
Diagram from the Kennel Management System. This diagram illustrates events involving
the availability of kennel spaces.

Figure 1-7. State chart Diagram for Kennel Spaces
Exercise 106: Reading a State chart Diagram
1. What event causes a kennel space, or pen, to enter the Defined state?
2. What events (from which states) cause a pen to enter the Available state?
3. What state does a pen enter when it’s currently in the Available state, and a
Dismantled event occurs?
4. How can a pen go from the In Use state to the Deconstructed state?
Deployment Diagrams
A Deployment Diagram depicts how the deployable units of your system—applications,

components, data stores, etc.—are assigned to various nodes, as well as how the nodes
communicate with each other and with devices. It’s useful both as a map of your system
and as a means for studying the load across your system. Figure 1-8 presents a simple
example of a Deployment Diagram for the Kennel Management System.
Figure 1-8. Deployment Diagram for the Kennel Management System
Exercise 107: Reading a Deployment Diagram
1. Which processes are running on the reception station?
2. How is the KMS server connected to the telephone?
3. How does the owner’s PC access pet information on the KMS server?
4. How does information go from the care giver station to the reception station?
A Package Diagram depicts how related elements of your design are grouped together, as
well as how the groups depend upon each other. It’s useful for dividing a complex design
into multiple, more manageable smaller designs. Figure 1-9 presents an example of a
Package Diagram from the Kennel Management System.

Figure 1-9. Package Diagram of the Kennel Management System
Exercise 108: Reading a Package Diagram
1. Which packages make use of information from the KMS Interfaces package?
2. Which packages does the KMS Central Classes package make use of?
In UML, the dependency arrows (- - - - >) indicate the direction of knowledge and control.
To those people familiar with ERDs and DFDs, this seems exactly backwards. Their
instinct is to interpret Figure 1-9 as meaning that KMS Interfaces make use of Care Giver
Classes, Accounting Classes, Reservation Classes, and KMS Central Classes.
The UML convention isn’t quite as backwards as it seems. How would a class in Care
Giver Classes make use of an interface in KMS Interfaces? By calling its methods, of
course. And very likely, the class would pass data to the interface as well. So control and
even some data do indeed flow in the direction of the dependency arrow.
And if that doesn’t help you to keep the meaning of the arrows straight, I can only
apologize, and claim innocence: I didn’t write the UML (though its convention seems
“correct” in my biased perspective). I do know that this is a source of confusion for ERD
and DFD practitioners; and I hope that this warning will help to minimize your confusion.

Object-Oriented (OO) Software Development Process (SDP)
Introduction
Software engineering is a systematic and disciplined methodology for producing reliable

and workable software using a suite of sound engineering principles. For any system to be
engineered and sustained, we need an array of trend-setting technologies, proven
processes, scalable infrastructures and adaptive resources including humans. Software
engineering also like other core engineering disciplines needs a host of standardized,
industrial-strength and well-defined development processes.
There are a bewildering array of software applications and types. Primarily software is
classified into two: system and application software. A typical system software mainly
interacts with the computer, its components and peripherals such as printer, webcam,
scanner, mouse, USB drive etc besides with all the network infrastructure solutions such
as routers, switches, bridges, hubs, gateways, etc. The application software generally
interacts with the system software. The details are as follows.
1. Software Types
System Software is a collection of programs written to service other programs. Some

system software such as program language compilers, interpreters and file systems process
complex, but determinate, information structures. Other system software, such as device
drivers, operating systems, protocols, etc, are destined to process largely indeterminate
data. Thus the primary characteristics of system software are as given below. It
• Needs to interact with computer hardware and other peripherals,
• Might be used by multiple applications and users
• Involves concurrent operation that requires scheduling, slicing, time & resource
sharing, and sophisticated process management
• Includes complex data structures and multiple external interfaces
Middleware is an emerging software type that sits in between application and system
software facilitating smooth interaction, collaboration, communication, integration,
connectivity, and adaptation purposes.
Real-time Software represents programs that monitor / analyze / control real world events
as they occur. Elements of real-time software include a data gathering component that

collects and formats information from an external environment, an analysis component

that transforms information as required by the application, a control / output component
that responds to the external environment, and a monitoring component that coordinates
all other components so that real-time response can be maintained. Thus a real-time
system must respond within strict time constraints.
Engineering and scientific software has been all along characterized primarily by
number crunching algorithms. Applications range from astronomy to volcanology, from
automotive stress analysis to space shuttle orbital dynamics, and from molecular biology
to automated manufacturing. These are processing-intensive applications.
Embedded software is becoming hugely popular these days. They are found in consumer
electronics, avionics, handhelds, wearables, portables, mobiles, automobiles, smart homes,
and manufacturing industries. Embedded software resides in real-only memory and is used
to control products and systems for the consumer and industrial markets. Embedded
software can perform very limited and esoteric functions such as key pad control for a
microwave oven or provide significant function and control capabilities (e.g., digital
functions in an automobile such as fuel control, dashboard displays, braking systems etc.).
Communication software facilitates seamless mobility of mobile users and devices

besides ensuring reliable communication among devices.
Artificial Intelligence (AI) software makes use of non-numerical algorithms to solve

complex problems that are not amenable to computation or straightforward analysis. An
active area is expert systems, also called knowledge-based systems. Other areas of AI are
machine learning, natural language processing, speech recognition, pattern recognition,
theorem proving, game playing, etc. Incorporating intelligence inside the software are the
critical objective of AI
There are many application software applications such as web-based, wireless, desktop,
financial, enterprise, logistics, retail, energy, governmental, healthcare and other business
software applications. Business software represents the discrete systems such as
enterprise resource planning (ERP), supply chain management (SCM), customer
relationship management (CRM), inventory, knowledge, and content management. Most
of the business software are data intensive and data-processing applications.
Similarly there are promising methods, technologies, strategies, tools, infrastructures, and
resources. Thus an appropriate software development process model has to be strictly

chosen based on the nature of the final software system to be built. In this chapter, we are
to see the well-known development process models.
2. Development Process Models
2.1 The Linear Sequential Developmental Model for software engineering is called the
classic life cycle or the waterfall model. This model suggests a systematic, sequential
approach to software development that begins at the system level and progresses through
analysis, design, coding, testing and maintenance. Modeled after the conventional
engineering cycle, the linear sequential model encompasses the following activities:
• System / Information engineering and modeling – Because software is always

part of a larger system, work begins by establishing requirements for all system
elements and then allocating some subset of these requirements to software. This
system view is essential when software must interface with other elements such as
hardware, people, and databases. System engineering and analysis encompasses
requirements gathering at the system level with a small amount of top-level
analysis and design. Information engineering encompasses requirements gathering
at the strategic business level and at the business area level.
• Software requirement analysis – The requirements gathering process is

intensified and focused specifically on software. To understand the nature of the
programs to be built, the software engineer (analyst) must understand the
information domain for the software as well as required function, behavior,
performance, and interfacing. Requirements for both the system and the software
are documented and reviewed with the customer.
• Design –The design process translates software requirements into a representation

of the software that can be assessed for quality before code generation begins. Like
requirements, the design is documented and becomes part of the software
configuration.
• Code generation – The design must be translated into a machine readable form.
• Testing – Once code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, assuring that all statements
have been tested and on the functional externals – that is, conducting tests to

uncover errors and ensure that defined input will produce actual results that agree
with required results.
• Maintenance – Software will undoubtedly undergo change after it is delivered to

the customer.
The Prototyping Model – The prototyping paradigm begins with requirements gathering.
Developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
A quick design then occurs. The quick design focuses on a representation of those aspects
of the software that will be visible to the customer / user. The quick design leads to the
construction of a prototype. The prototype is evaluated by the customer / user and is used
to refine requirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, at the same time enabling the developer to
better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements. If a

working prototype is built, the developer attempts to make use of existing program
fragments or applies that enable working programs to be generated quickly. Prototyping is
an effective paradigm for software engineering.
Rapid Application Development (RAD) model is a linear sequential software

development process model that emphasizes an extremely short development cycle. The
RAD model is a high-speed adaptation of the linear sequential model in which rapid
development is achieved by using a component-based construction approach. If
requirements are well understood and project scope is constrained, the RAD process
enables a development team to create a fully functional system within very short time
periods. The RAD approach encompasses the following phases:
• Business modeling – The information flow among business functions is modeled

in a way that answers the following questions: what information drives the
business process? What information is generated? Who generates its? Where does
the information go? Who processes it?
• Data modeling – the information flow defined as part of the business modeling
phase is refined into a set of data objects that are needed to support the business.
The characteristics (attributes) of each object are identified and the relationships
between these objects are defined.
• Process modeling – the data objects defined in the data modeling phase are
transformed to achieve the information flow necessary to implement a business
function. Processing descriptions are created for adding, modifying, deleting, or
retrieving a data object
• Application generation – RAD uses the fourth generation techniques to create

software.
• Testing and turnover – Since the RAD process emphasizes reuse, many of the
program components have already been testing.
2.2 Evolutionary Software Process Models – There is growing recognition that software,
like all complex systems, evolves over a period of time. Thus a few interesting
evolutionary models have emerged. Below a brief of each is supplied.
The Incremental model combines elements of the linear sequential model with the
iterative philosophy of prototyping. Each linear sequence produces a deliverable increment
of the software. For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production
functions in the first increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment. Thus when an
incremental model is used, the first increment is often a core product. That is, basic
requirements are addressed but many supplementary features remain undelivered. The
core product might be used by the customer or be subjected for detailed review. As a result
of use and / or evaluation, a plan is being developed for the next increment. The plan
addresses the modification of the core product to better meet the needs of the customer and
the delivery of additional features and functionality. This process gets repeated following
the delivery of each increment, until the complete product is produced. The iterative
process, like prototyping and other evolutionary approaches, is iterative in nature.
The Spiral Model is an evolutionary software process model that couples the iterative
nature of prototyping with the controlled and systematic aspects of the linear sequential
model. In this spiral model, software is developed in a series of incremental releases.
During early iterations, increasingly more complete versions of the engineered system are
produced. The spiral model is divided into a number of task regions.

1. customer communication – tasks required to establish effective communication

between developer and customer
2. planning – tasks required to define resources, timelines, and other project related
information
3. risk analysis – tasks required to assess both technical and management risks
4. engineering tasks required to build one or more representations of the application
5. construction & release – tasks required to construct, test, install and provide user
support
6. customer evaluation – tasks required to obtain customer feedback based on

evaluation of the software representations created during the engineering stage and
implemented during the installation stage
Each of the six regions is populated by a series of subtasks that are adapted according to
the characteristics of the project to be undertaken. The spiral model is a realistic approach
to the development of large scale systems and software.
Thus far, we have seen both old and new process models for generic software engineering.
Sometimes the process is being termed as software development life cycle (SDLC). There
are several techniques for simplifying each phase of this development process. Traditional
approaches such as functional / procedure –oriented and structured methods (Structured
analysis, design and implementation) C is the primary structured programming language.
In the recent past, OO paradigm (OO analysis, design, programming, and testing) have
emerged in the software market. Due to its soaring popularity and acceptance among the
professionals as well as the customers, it has become the dominant paradigm as far as the
task of engineering software for various personal, business as well as system domains.
Equally OO paradigm is being strengthened and supported by the grand arrival of a host of
OO programming languages such as C++, Java, C#, VB.NET etc.
3. Object-Oriented Systems Development
We live in a world of objects. These objects exist in nature, in man-made entities, in

business and in the products we use everyday. They can be differentiated, categorized,
described, organized, combined, manipulated and created. Thus while forming software
abstractions for the real-world problems, it is logical, prudent and natural to think of
software solutions as an interacting, collaborating, and coexisting software objects. This

concept induced many to come out with an increasing array of OO technologies, methods,
models, and approaches. The interesting aspect of OO method includes realizing of
reusability. This reuse of program components leads to faster software development of
bug-free, quality-conscious, reusable, scalable, secure and flexible software applications.
Also OO software is easy to conceptualize, develop, deploy, manage, handle, use, and
maintain for analysts, architects, developers, administrators, and end users.
Building High-Quality Software - The software process transforms the users’ needs via
the application domain to a formidable software service / solution / product that satisfies
that sincerely satisfies those needs. Once the software is build, it is mandatory to check
whether the built software is free of errors, bugs, risks, dangers, defects and infirmities
besides it accomplishes all the core requirements, intentions and expectations of the users.
Thus customer satisfaction and delight is the main and focused target for software services
and solutions providers. There are two basic approaches for testing software systems. That
is, we can test a system according to how it has been built or what it should do. There are
four quality measures for evaluating a system: correspondence, correctness, verification,
and validation. Correspondence measures how well the delivered system matches the
needs of the operational environment, as described in the original requirements statement.
Validation is the task of predicting correspondence. True correspondence cannot be
determined until the system is fully built. Correctness measures the consistency of the
product requirements with respect to the design specification. Verification is the exercise
of determining correctness.
Correctness always is objective. That is, given a specification and a product, it should be
possible to determine if the product precisely satisfies the requirements of the
specification. Validation is always subjective. That is, it checks the appropriateness of the
specification itself. In hindsight, verification checks whether we build the product right
whereas the validation evaluates whether we build the right product. Validation begins as
soon as the project starts, but verification can begin only after a specification has been
accepted. Thus realizing high-quality software is ensured through these checks. OO
system development technologies, methodologies, strategies, tools, infrastructures and
resources are guaranteeing high-quality software. In the following, we are to discuss in
detail all about the OO software development.

The activities involved in developing software in an OO perspective are
1. OO Analysis using use case technique
2. OO Design
3. Prototyping
4. Component-based Development
5. Incremental Testing
3.1 The OO Analysis (OOA) phase of software development is concerned with

identifying the system requirements and determining all the classes and their relationship
to other classes in the problem domain. In order to understand the system requirements
fully, comprehensively and precisely, we need to identify the end users (customers) or the
actors who are going to handle and use the system after its completion. Scenarios are used
to help analysts and domain experts to understand the requirements cleanly as they are a
great way of examining the relationships between the users and the objects and the
interrelationships among the objects. Ivar Jacobson has coined the word “use case” for a
scenario. That is, a use case is a typical interaction between a user and a system that
fulfills users’ goals, tasks and needs.
Thus in order to fully understand all the interactions, collaborations, communications,

operations, behaviors, and exceptions happening among the system components and the
users, we need to extract and gather all the scenarios. Further on, the set of compact
scenarios or use cases are being captured and gleaned through a series of interviews with
the potential users, extracting answers for many questions from them, and through
observation of users while handling such kinds of target systems. Expressing these high-
level processes and interactions with customers in a scenario and analyzing it is referred to
as use-case modeling. The use case model represents the users’ view of the final system.
Looking at the physical objects in the system also provides vital clue and relevant
information towards the core software classes and objects in the target system solution.
For example, in an online course registration system in a university, the possible tangible
objects are students, course-list, teachers, registrar, etc. The intangible objects include data
tables, data entry screens, data structures, and so forth.
Thus gathering system requirements in the form of use cases, studying, analyzing,
prioritizing, organizing, cataloguing, and documenting them for future references,

estimating risks, identifying the relevant classes, and establishing the plausible
relationships between the objects of those classes are some of the important activities of
the OO analysis phase.
3.2 The goal of Object-Oriented Design (OOD) phase is to design the classes identified
during the earlier phase and the user interface. Identifying and defining additional objects
and classes that support implementation of the requirements are the other important tasks
in this very crucial and critical phase. If the design is right, the product or the system to be
built would be right. During interface design, there will be a need for thinking about
incorporating additional objects. The activities of the design phase are summarized as
follows
• Design and refine classes
• Design and refine attributes
• Design and refine methods
• Design and refine structures
• Design and refine associations
Thus designing and refining the class and object structures, components and their
collaborations are the leading activities of the design phase.
In the picture drawn using IBM Rational tool, there are two classes (Shape and Controller)
and two subclasses (Rectangle and Circle) of Shape class. Each class has its own attributes
and methods as indicated in the class diagram.

3.3 Prototyping – It is gaining momentum to construct a prototype of the some of the key
system components before embarking on full-fledged system development. As often told
that a picture is worth a thousand words, a prototype is worth a thousand pictures. A
prototype is a version of a software product developed in the early stages of the product’s
life cycle for specific, experimental purposes. A prototype enables to fully understand how
easy or difficult to implement certain aspects in the final commercial version. Also we can
understand what novel features need to be added or what sorts of risks are involved in
system development. A prototype is to tell an overall view of the system under
development. A prototype would clearly tell what sort of changes the developer has to
make, what sort of software toolkits, languages, and technologies need to be used etc.
Thus the benefits accrued out of prototyping are manifold including rescuing the project
from going down. The navigability, usability, and usefulness of user interfaces can be
enhanced with this prototyping. There are many commonly accepted prototypes as
follows.
1. A horizontal prototype is a simulation of the interface. In other words, it has

the entire user interface ready but contains no functionality.
2. A vertical prototype is a subset of the system features with complete

functionality. The advantage with this is that it is possible to thoroughly check
the few implemented functionality
3. An analysis prototype is an aid for exploring the problem domain. This class of
prototypes is used to inform the user and demonstrate the proof of a concept.

4. A domain prototype is an aid for the incremental development of the ultimate

software solution. It is often is used as an effective tool for the staged delivery
of subsystems to the users or other members of the development team. It
demonstrates the feasibility of the implementation and eventually will evolve
into a deliverable product.
Thus prototyping is turning out to be a useful exercise at almost any stage of the
development.
3.4 Component-based Development (CBD) – Manufacturers are adept in reusing and

assembling various prefabricated components for custom development. In the similar way,
software systems are being custom built easily, and quickly using a set of already
developed, tested, verified, validated, and deployed software components. There are
computer-aided software engineering (CASE) tools that helps to develop information
systems rapidly and seamlessly. The main goal of CASE technology is the automation of
the entire information system’s development life cycle process using a set of integrated
software tools, such as requirements gathering, storing, analyzing, modeling, designing,
debugging and automatic code generation. There are integrated development environments
(IDEs), compilers, editors, toolkits and other simplifying solutions that facilitate the
software development team immensely in satisfying the modern requirements of
accomplishing more with less (time, resources, investment, etc.).
Legacy applications coded using old technologies such as COBOL are made interoperable
with the modern applications using concepts such as wrapper, helper software suite etc.
Thus off-the-shelf components, wrappers, classes and other software modules are
encouraging the component-based development. The software components are the
functional units of a program and building blocks for offering a collection of core,
customized, and personalized services. Thus CBD is emerging as the hot cake for the
developers to develop next-generation software applications using the time-tested, quality-
conscious, refined, and highly reusable software components.
3.5 Rapid Application Development (RAD) is a set of software tools such as Delphi,
Visual Basic, VisualAge, or PowerBuilder and viable techniques that can be used to build
an application faster than typically possible with traditional methods. RAD is often
associated with development of software in quick time. The main objective of RAD is to
build a version of an application quickly to see whether the architects have understood the

system requirements correctly and the developers are moving in the right direction.
Further it determines whether the system does what it is expected to do. Thus RAD is an
interesting move in order to visualize what is to come and if there is any deviation, it can
be corrected in time.
3.6 Incremental testing – In the olden days, after fully completing the system or product
only, the testing team will come into picture. This will waste a lot of time and dollars and
hence in order to reduce the project completion time, testing is introduced at the earlier
stage. That is, when a small building block (a testable class or software module), it is sent
to testing department for thorough and comprehensive testing.
In summary, in the initial sections, we have discussed generic software development

process models, and subsequently we have concentrated on OO software development life
cycle (OO SDLC) as it is an accepted fact that OO paradigm is doing wonders for not only
producing object-oriented software but also for components and services that can be
accessed over the net (Intranet, the Internet and extranet).

UNIT - 5
Software Quality Assurance
In a robust system,
 Each component will behave correctly
 Collective behavior is correct
 No incorrect collective behavior will be produced
We need to test each component / object. We also should examine collective behaviors to
ensure maximum operational reliability. Although programming techniques have
improved immensely since the early years, the process of finding and correcting errors in
programming is still difficult, complicated and complex. Debugging is the process of
finding out where something went wrong and correcting the code to eliminate the errors or
bugs that cause unexpected results. Precisely speaking, the elimination of the syntactical
bug is the process of debugging whereas the detection and elimination of the logical bug.
The logical bugs are extremely subtle and may need a great deal of effort to eliminate
them.
One reason why quality assurance is needed is because computers are infamous for doing
what we tell them to do, not necessarily what we want them to do. To close this gap, the
code must be free of errors or bugs that cause unexpected results. For example, if an
incorrect result was produced at the end of a long series of computations, perhaps we
forgot to assign the correct value to a variable, chose the wrong operator, or used an
incorrect formula.
The kind of errors we might encounter when we run our program
1. Language (syntax) errors result from incorrectly constructed code, such as an

incorrectly typed keyword or some necessary punctuation omitted.
2. Run-time errors occur and are detected as the program is running, when a
statement attempts an operation that is impossible to carry out. For example, if the
program tries to access a nonexistent object say a file, a run-time error will occur

3. Logic errors occur when code does not perform the way we intended. The code
might be syntactically valid and run without performing any invalid operations and
yet produce incorrect results. Logic errors produce run-time errors
Quality assurance testing can be divided into two major categories: error-based testing and
scenario-based testing. Error-based testing techniques search a given class’s method for
particular clues of interests, then describe how these cues should be tested. For example,
we want to test the payrollComputation method of an Employee class:
anEmployee.computePayroll (hours). To test this method, we must try different values for
hours (say 40, 0, 100, -10) to see if the program can handle them (this is also called as the
testing the boundary conditions). The method must be able to handle any value; if not, the
error must be recorded and reported. Similarly, the technique can be used to perform
integration testing by testing the object that processes a message and not the object that
sends the message.
Scenario-based testing, also called usage-based testing, concentrates on the user does, not
what the product does. This means capturing use cases and the tasks users perform, then
performing them and their variants as tests. These scenarios also can identify interaction
bugs. Scenario-based tests tend to exercise multiple subsystems in a single test, because
that is what users do.
Testing Strategies
The extent of testing a system is controlled by many factors, such as the risks involved,
limitations on resources, and deadlines. The testing strategy within the constraints has to
use a combination of these: black box testing, white box testing, top-down testing and
bottom-up testing.
Black Box testing – The concept of the black box is used to represent a system whose
inside workings are not available for inspection. In a black box, the test item is treated as
black, since its logic is unknown. All that is known is what goes in and what comes out or
the input and output. Writing a user manual as an example of a black box approach to
requirements. The user manual does not show the internal logic, because the users of the
system do not care about what is made the system
In black box testing, we try various inputs and examine the resulting output. We can learn
what the box does but nothing about how this conversion is implemented. The black box
testing technique also can be used for scenario-based tests, where the system’s inside may

not be available for inspection but the input and output are defined through use cases or
other analysis information.
White box testing assumes that the specific logic is important and must be tested to
guarantee the system’s proper functioning. The main use of the white box is in error-based
testing, when we already have tested all objects of an application and all external or public
methods of an object that we believe to be of greater importance. In white box testing, we
are looking for bugs that have a low probability of execution, have been carelessly
implemented, or were overlooked previously
One form of white box testing, called path testing, is to check each path in an object’s
method. Two types of path testing are statement testing coverage, and branch testing
coverage.
Statement testing coverage – The main idea of statement testing coverage is to test every
statement in the object’s method by executing it at least once.
Branch testing coverage – The main idea behind this testing is to perform enough tests to
ensure that every branch alternative has been executed at least once under some test.
Top-down testing assumes that the main logic or object interactions and system messages
of the application need more testing than an individual object’s methods or supporting
logic. A top-down strategy can detect the serious design flaws early in the implementation.
In theory, top-down testing should find critical design errors early in the testing process
and significantly improve the quality of the delivered software because of the iterative
nature of the test. A top-down strategy supports testing the user interface and event-driven
systems. Testing the user interface using a top-down approach means testing interface
navigation. This approach can test the navigation through screens and verify that it
matches the requirements. Users can also see at an early stage, how the final application
will look and feel. This approach is for scenario-based testing. This testing is useful for
testing subsystems and systems integration.
Bottom-up testing starts with the details of the system and proceeds to higher-levels by a
progressive aggregation of details until they collectively fit the requirements for the
system. This approach is more appropriate for testing the individual objects in a system.
Here we test each object, then combine them and test their interaction and the messages
passed among objects by utilizing the top-down approach.

UML Tutorial
The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems, as
well as for business modeling and other non-software systems. The UML
represents a collection of best engineering practices that have proven successful in
the modeling of large and complex systems.1 The UML is a very important part of
developing objects oriented software and the software development process. The
UML uses mostly graphical notations to express the design of software projects.
Using the UML helps project teams communicate, explore potential designs, and
validate the architectural design of the software.
Goals of UML
The primary goals in the design of the UML were:
1. Provide users with a ready-to-use, expressive visual

modeling language so they can develop and exchange
meaningful models.
2. Provide extensibility and specialization mechanisms to

extend the core concepts.
3. Be independent of particular programming languages and

development processes.
4. Provide a formal basis for understanding the modeling

language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as

collaborations, frameworks, patterns and components.
7. Integrate best practices.
Why Use UML?
As the strategic value of software increases for many companies, the industry looks for
techniques to automate the production of software and to improve quality and reduce cost

and time-to-market. These techniques include component technology, visual

programming, patterns and frameworks. Businesses also seek techniques to manage the
complexity of systems as they increase in scope and scale. In particular, they recognize the
need to solve recurring architectural problems, such as physical distribution, concurrency,
replication, security, load balancing and fault tolerance. Additionally, the development for
the World Wide Web, while making some things simpler, has exacerbated these
architectural problems. The Unified Modeling Language (UML) was designed to respond
to these needs.
Each UML diagram is designed to let developers and customers view a software system
from a different perspective and in varying degrees of abstraction. UML diagrams
commonly created in visual modeling tools include:1
Use Case Diagram displays the relationship among actors and use cases.1
Class Diagram models class structure and contents using design elements such as classes,
packages and objects. It also displays relationships such as containment, inheritance,
associations and others. 1
Interaction Diagrams
• Sequence Diagram displays the time sequence of the objects participating in the
interaction. This consists of the vertical dimension (time) and horizontal dimension
(different objects).1
• Collaboration Diagram displays an interaction organized around the objects and

their links to one another. Numbers are used to show the sequence of messages.1
State Diagram displays the sequences of states that an object of an interaction goes
through during its life in response to received stimuli, together with its responses and
actions.1
Activity Diagram displays a special state diagram where most of the states are action
states and most of the transitions are triggered by completion of the actions in the source
states. This diagram focuses on flows driven by internal processing.1
Physical Diagrams

• Component Diagram displays the high level packaged structure of the

code itself. Dependencies among components are shown, including source
code components, binary code components, and executable components. Some
components exist at compile time, at link time, at run times well as at more
than one time.1
• Deployment Diagram displays the configuration of run-time processing

elements and the software components, processes, and objects that live on
them. Software component instances represent run-time manifestations of code
units
A use case is a set of scenarios that describing an interaction between a user and a system.
A use case diagram displays the relationship among actors and use cases. The two main
components of a use case diagram are use cases and actors.
An actor is represents a user or another system that will interact with the system you are
modeling. A use case is an external view of the system that represents some action the
user might perform in order to complete a task.
When to Use: Use Cases Diagrams
Use cases are used in almost every project. The are helpful in exposing requirements and
planning the project. During the initial stage of a project most use cases should be defined,
but as the project continues more might become visible.
How to Draw: Use Cases Diagrams
Use cases are a relatively easy UML diagram to draw, but this is a very simplified
example. This example is only meant as an introduction to the UML and use cases. If
you would like to learn more see the Resources page for more detailed resources on UML.

Start by listing a sequence of steps a user might take in order to complete an action. For
example a user placing an order with a sales company might follow these steps.
1. Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.
These steps would generate this simple use case diagram:
This example shows the customer as a actor because the customer is using the ordering
system. The diagram takes the simple steps listed above and shows them as actions the
customer might perform. The salesperson could also be included in this use case diagram
because the salesperson is also interacting with the ordering system.

From this simple diagram the requirements of the ordering system can easily be derived.
The system will need to be able to perform actions for all of the use cases listed. As the
project progresses other use cases might appear. The customer might have a need to add
an item to an order that has already been placed. This diagram can easily be expanded
until a complete description of the ordering system is derived capturing all of the
requirements that the system will need to perform.
Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements
such as classes, packages and objects.2 Class diagrams describe three different
perspectives when designing a system, conceptual, specification, and implementation.1
These perspectives become evident as the diagram is created and help solidify the design.
This example is only meant as an introduction to the UML and class diagrams. If you
would like to learn more see the Resources page for more detailed resources on UML.
Classes are composed of three things: a name, attributes, and operations. Below is an
example of a class.
Class diagrams also display relationships such as containment, inheritance, associations

and others.2 Below is an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The
association shows the relationship between instances of classes. For example, the class
Order is associated with the class Customer. The multiplicity of the association denotes
the number of objects that can participate in then relationship.1 For example, an Order
object can be associated to only one customer, but a customer can be associated to many
orders.
Another common relationship in class diagrams is a generalization. A generalization is

used when two classes are similar, but have some differences. Look at the generalization
below:
In this example the classes Corporate Customer and Personal Customer have some
similarities such as name and address, but each class has some of its own attributes and
operations. The class Customer is a general form of both the Corporate Customer and
Personal Customer classes.1 This allows the designers to just use the Customer class for
modules and do not require in-depth representation of each type of customer.

When to Use: Class Diagrams
Class diagrams are used in nearly all Object Oriented software designs. Use them to
describe the Classes of the system and their relationships to each other.
How to Draw: Class Diagrams
Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed
and useful diagrams a person would have to study UML and Object Oriented principles
for a long time. Therefore, this page will give a very high level overview of the process.
To find list of where to find more information see the Resources page.
Before drawing a class diagram consider the three different perspectives of the system the
diagram will present; conceptual, specification, and implementation. Try not to focus on
one perspective and try see how they all work together.
When designing classes consider what attributes and operations it will have. Then try to
determine how instances of the classes will interact with each other. These are the very
first steps of many in developing a class diagram. However, using just these basic
techniques one can develop a complete view of the software system.

This example is only meant as an introduction to the UML and use cases. If you would
like to learn more see the Resources page for more detailed resources on UML.
Interaction diagrams model the behavior of use cases by describing the way groups of
objects interact to complete the task. The two kinds of interaction diagrams are sequence
and collaboration diagrams. This example is only meant as an introduction to the UML
and interaction diagrams. If you would like to learn more see the Resources page for a list
of more detailed resources on UML.
When to Use: Interaction Diagrams
Interaction diagrams are used when you want to model the behavior of several objects in a
use case. They demonstrate how the objects collaborate for the behavior. Interaction
diagrams do not give a in depth representation of the behavior. If you want to see what a
specific object is doing for several use cases use a state diagram. To see a particular
behavior over many use cases or threads use an activity diagrams. 1
How to Draw: Interaction Diagrams
Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate

the interaction of objects in a use case. Sequence diagrams generally show the sequence
of events that occur. Collaboration diagrams demonstrate how objects are statically
connected. Both diagrams are relatively simple to draw and contain similar elements. 1
Sequence diagrams:
Sequence diagrams demonstrate the behavior of objects in a use case by describing the
objects and the messages they pass. the diagrams are read left to right and descending.
The example below shows an object of class 1 start the behavior by sending a message to
an object of class 2. Messages pass between the different objects until the object of class
1 receives the final message.

Below is a slightly more complex example. The light blue vertical rectangles the objects
activation while the green vertical dashed lines represent the life of the object. The green
vertical rectangles represent when a particular object has control. The represents when the
object is destroyed. This diagrams also shows conditions for messages to be sent to other
object. The condition is listed between brackets next to the message. For example, a
[condition] has to be met before the object of class 2 can send a message() to the object of
class 3.
The next diagram shows the beginning of a sequence diagram for placing an order. The
object an Order Entry Window is created and sends a message to an Order object to
prepare the order. Notice the the names of the objects are followed by a colon. The names
of the classes the objects belong to do not have to be listed. However the colon is required
to denote that it is the name of an object following the objectName:className naming
system.

Next the Order object checks to see if the item is in stock and if the [InStock] condition is
met it sends a message to create an new Delivery Item object.
The next diagrams adds another conditional message to the Order object. If the item is
[OutOfStock] it sends a message back to the Order Entry Window object stating that the
object is out of stack.
This simple diagram shows the sequence that messages are passed between objects to
complete a use case for ordering an item.

Collaboration diagrams:
Collaboration diagrams are also relatively easy to draw. They show the relationship
between objects and the order of messages passed between them. The objects are listed as
icons and arrows indicate the messages being passed between them. The numbers next to
the messages are called sequence numbers. As the name suggests, they show the sequence
of the messages as they are passed between the objects. There are many acceptable
sequence numbering schemes in UML. A simple 1, 2, 3... format can be used, as the
example below shows, or for more detailed and complex diagrams a 1, 1.1 ,1.2, 1.2.1...
scheme can be used.
The example below shows a simple collaboration diagram for the placing an order use
case. This time the names of the objects appear after the colon, such as :Order Entry
Window following the objectName:className naming convention. This time the class
name is shown to demonstrate that all of objects of that class will behave the same way.
State diagrams are used to describe the behavior of a system. State diagrams describe all
of the possible states of an object as events occur. Each diagram usually represents
objects of a single class and track the different states of its objects through the system.

When to Use: State Diagrams
Use state diagrams to demonstrate the behavior of an object through many use cases of the
system. Only use state diagrams for classes where it is necessary to understand the
behavior of the object through the entire system. Not all classes will require a state
diagram and state diagrams are not useful for describing the collaboration of all objects in
a use case. State diagrams are other combined with other diagrams such as interaction
diagrams and activity diagrams. 1
How to Draw: State Diagrams
State diagrams have very few elements. The basic elements are rounded boxes
representing the state of the object and arrows indicting the transition to the next state.
The activity section of the state symbol depicts what activities the object will be doing
while it is in that state.
All state diagrams being with an initial state of the object. This is the state of the object
when it is created. After the initial state the object begins changing states. Conditions
based on the activities can determine what the next state the object transitions to.

Below is an example of a state diagram might look like for an Order object. When the
object enters the Checking state it performs the activity "check items." After the activity
is completed the object transitions to the next state based on the conditions [all items
available] or [an item is not available]. If an item is not available the order is canceled. If
all items are available then the order is dispatched. When the object transitions to the
Dispatching state the activity "initiate delivery" is performed. After this activity is
complete the object transitions again to the Delivered state.
State diagrams can also show a super-state for the object. A super-state is used when many
transitions lead to the a certain state. Instead of showing all of the transitions from each
state to the redundant state a super-state can be used to show that all of the states inside of

the super-state can transition to the redundant state. This helps make the state diagram
easier to read.
The diagram below shows a super-state. Both the Checking and Dispatching states can
transition into the Canceled state, so a transition is shown from a super-state named
Active to the state Cancel. By contrast, the state Dispatching can only transition to the
Delivered state, so we show an arrow only from the Dispatching state to the Delivered
state.
Activity diagrams describe the workflow behavior of a system. Activity diagrams are
similar to state diagrams because activities are the state of doing something. The diagrams
describe the state of activities by showing the sequence of activities performed. Activity
diagrams can show activities that are conditional or parallel.
When to Use: Activity Diagrams
Activity diagrams should be used in conjunction with other modeling techniques such as
interaction diagrams and state diagrams. The main reason to use activity diagrams is to
model the workflow behind the system being designed. Activity Diagrams are also useful
for: analyzing a use case by describing what actions need to take place and when they
should occur; describing a complicated sequential algorithm; and modeling applications
with parallel processes. 1

However, activity diagrams should not take the place of interaction diagrams and state
diagrams. Activity diagrams do not give detail about how objects behave or how objects
1
collaborate.
How to Draw: Activity Diagrams
Activity diagrams show the flow of activities through the system. Diagrams are read from
top to bottom and have branches and forks to describe conditions and parallel activities. A
fork is used when multiple activities are occurring at the same time. The diagram below
shows a fork after activity1. This indicates that both activity2 and activity3 are occurring
at the same time. After activity2 there is a branch. The branch describes what activities
will take place based on a set of conditions. All branches at some point are followed by a
merge to indicate the end of the conditional behavior started by that branch. After the
merge all of the parallel activities must be combined by a join before transitioning into the
final activity state.
Software Design Center

HOW TO DRAW YOURDON AND COAD DIAGRAMS
What is Yourdon & Coad's OOA/OOD?

Yourdon & Coad's Object-Oriented Analysis and Design (OOA/OOD) is an object-
oriented method that precedes UML. To draw a Yourdon & Coad diagram, simply
complete these five steps:
find classes and objects
identify the structures
define subjects
define attributes
define services

A Yourdon & Coad Class Diagram
Common Yourdon & Coad Notations
Class & Object
Objects and classes are abstractions of entities with

exclusive services and attributes.
Whole-Part Relationships
Whole-part relationship refers to objects that contain

one or more other objects. There are several types of
whole-part relationships including: assembly-parts
(airplane-wings), container-contents (cabinet-files), and
collection-members (organization-members).

Generalization-Specialization (Gen-Spec)
Relationships
Generalization-Specialization relationships refer to
classes that inherit attributes and services from other
classes. One class can inherit from multiple
superclasses.
Connections
Connections illustrate the dependency of one object on
the services or processing of another object.

Below is a possible activity diagram for processing an order. The diagram shows the flow
of actions in the system's workflow. Once the order is received the activities split into two
parallel sets of activities. One side fills and sends the order while the other handles the
billing. On the Fill Order side, the method of delivery is decided conditionally.
Depending on the condition either the Overnight Delivery activity or the Regular Delivery
activity is performed. Finally the parallel activities combine to close the order.

There are two types of physical diagrams: deployment diagrams and component
diagrams. Deployment diagrams show the physical relationship between hardware and
software in a system. Component diagrams show the software components of a system
1
and how they are related to each other. These relationships are called dependencies.
When to Use: Physical Diagrams
Physical diagrams are used when development of the system is complete. Physical
diagrams are used to give descriptions of the physical information about a system.
How to Draw: Physical Diagrams
Many times the deployment and component diagrams are combined into one physical
diagram. A combined deployment and component diagram combines the features of both
diagrams into one diagram.

The deployment diagram contains nodes and connections. A node usually represents a
piece of hardware in the system. A connection depicts the communication path used by
the hardware to communicate and usually indicates a method such as TCP/IP.
The component diagram contains components and dependencies. Components represent

the physical packaging of a module of code. The dependencies between the components
show how changes made to one component may affect the other components in the
system. Dependencies in a component diagram are represented by a dashed line between
two or more components. Component diagrams can also show the interfaces used by the
1
components to communicate to each other.
The combined deployment and component diagram below gives a high level physical
description of the completed system. The diagram shows two nodes which represent two
machines communicating through TCP/IP. Component2 is dependant on component1, so
changes to component 2 could affect component1. The diagram also depicts component3
interfacing with component1. This diagram gives the reader a quick overall view of the
entire system.

Designing Classes
OO development requires us to think in terms of objects and classes. The classes organize
related properties into units that stand on their own. OO Design requires taking the objects
identified during OO Analysis and designing classes to represent them. That is, class
designers having identified the classes and their interactions, he could start designing
classes. Underlying the functionality of any application is the quality of its design. In this
chapter, the objective is to look at guidelines and approaches to use in designing classes
and their methods.
Designing Classes the Process
In the last chapter, we looked at the OO design process. In this, we focus on the step 1 of
the OO design process.
1. Apply Design axioms to design classes, their attributes, methods, associations,

structures and protocols
 Refine and complete the static UML class diagram by adding details to that
diagram
 Refine attributes

 Design methods and the protocols by utilizing a UML activity diagram to

represent the method’s algorithm
 Refine the associations between classes if required
 Refine the class hierarchy and design with inheritance
2. Iterate and refine
Class Visibility – It is important to object-oriented design to define the public protocol

between the associated classes in the application. A class also might have a set of methods
that can be accessed internally. This private protocol (visibility) of the class includes
messages that normally should not be sent from other objects and it is accessible only to
operations of that class. That is, in private protocol, only the class itself can use the
method. The public protocol (visibility) defines the stated behavior of the class as a citizen
in a population and is important information for users as well as future descendants, so it
is accessible to all classes. If the methods or attributes can be used by the class itself or its
subclasses, a protected protocol is used.
Designing classes – refining attributes
Attributes identified in OO analysis must be refined with an eye on implementation during

this phase. In the design phase, detailed information must be added to the model (class
attributes and operations).
Attribute Types
1. Single-value attributes
2. Multiplicity or multivalue attributes
3. Reference to another object, or instance connection
Attributes represent the state of an object. When the state of the object changes, these
changes are reflected in the value of attributes. A single value attribute has only one value
or state. For example, attributes such as name, address, or salary are of the single-value
type. Mulivalue attributes can have a collection of many values at any point of time. For
example, if we want to keep track of the names of people who have called a customer
support line for help, we must use the multivalue attributes.

Instance connection attributes – a person might have one or more bank accounts. A
personal has zero to many instance connections to Account(s). Similarly, an account can
be assigned to one or more persons (joint accounts). Thus attribute can be a reference to
another object.
Refining Attributes for the BankClient Class
During OO Analysis, we have identified the following attributes
firstName
lastName
pinNumber
cardNumber
We need to add more information to these attributes, such as visibility, and

implementation type. Also additional attributes can be identified during this phase.
#firstName: String
#lastName: String
#pinNumber: String
#cardNumber: String
#account: Account (instance connection)
Designing Methods and Protocols
The main goal of this activity is to specify the algorithm for methods identified so far. If
we design the methods in some formal structure such as UML activity diagrams with an
OCL description, they can be converted to programming language manually or in
automated fashion using CASE tools. A class can provide several types of methods.
1. Constructor – Method that creates instances (objects) of the class
2. Destructor – The method that destroys instances
3. Conversion method – the method that converts a value from one unit of measure to
another
4. Copy method – the method that copies the contents of one instance to another
instance

5. Attribute set – The method that sets the values of one or more attributes
6. Attribute get – The method that returns the values of one or more attributes
7. I/O methods – The methods that provide or receive data to or from a device
8. Domain-specific – The method specific to the application
UML Operation Presentation – The following operation presentation has been suggested
by the UML. The operation syntax is
visibility name: (parameter-list): return-type-expression
where visibility is one of:
+ public visibility (accessibility to all classes)
# protected visibility (accessibility to subclasses and operations of the class)
- private visibility (accessibility only to operations of the class)
Here name is the name of the operation. Parameter-list: is a list of parameters separated by
commas, each specified by name: type-expression = default value (where name is the
name of the parameter, type-expression is the language-dependent specification of an
implementation type, and default-value is an optional value.
Return-type-expression: is a language-independent specification of the implementation of

the value returned by the method. If return-type is omitted, the operation does not return a
value.
Examples
+getName(): aName
+getAccountNumber (account: type): account Number
Designing methods, user interfaces and database access
In general, the methods’ algorithms are represented using UML activity diagrams, which
can be translated into any programming language.

CA 5202 - Object Oriented Analysis and Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CA 5202 - Object Oriented Analysis and Design

Uploaded by

Copyright:

Available Formats

CA 5202 – Object Oriented Analysis and Design

Object-Oriented (OO) Software Development Process (SDP)

Software engineering is a systematic and disciplined methodology for producing reliable

1.1 Software Types

System Software is a collection of programs written to service other programs. Some

• Needs to interact with computer hardware and other peripherals,

• Might be used by multiple applications and users

• Includes complex data structures and multiple external interfaces

AVCCE, Dept. of MCA – III Semester 1

Communication software facilitates seamless mobility of mobile users and devices

Artificial Intelligence (AI) software makes use of non-numerical algorithms to solve

AVCCE, Dept. of MCA – III Semester 2

2. Development Process Models

• System / Information engineering and modeling – Because software is always

• Software requirement analysis – The requirements gathering process is

• Design –The design process translates software requirements into a representation

AVCCE, Dept. of MCA – III Semester 3

• Maintenance – Software will undoubtedly undergo change after it is delivered to

Ideally, the prototype serves as a mechanism for identifying software requirements. If a

Rapid Application Development (RAD) model is a linear sequential software

• Business modeling – The information flow among business functions is modeled

AVCCE, Dept. of MCA – III Semester 4

• Application generation – RAD uses the fourth generation techniques to create

AVCCE, Dept. of MCA – III Semester 5

1. customer communication – tasks required to establish effective communication

4. engineering tasks required to build one or more representations of the application

6. customer evaluation – tasks required to obtain customer feedback based on

3. Object-Oriented Systems Development

We live in a world of objects. These objects exist in nature, in man-made entities, in

AVCCE, Dept. of MCA – III Semester 7

The activities involved in developing software in an OO perspective are

1. OO Analysis using use case technique

3.1 The OO Analysis (OOA) phase of software development is concerned with

Thus in order to fully understand all the interactions, collaborations, communications,

AVCCE, Dept. of MCA – III Semester 8

• Design and refine classes

• Design and refine attributes

• Design and refine methods

• Design and refine structures

• Design and refine associations

AVCCE, Dept. of MCA – III Semester 9

1. A horizontal prototype is a simulation of the interface. In other words, it has the

2. A vertical prototype is a subset of the system features with complete functionality.

AVCCE, Dept. of MCA – III Semester 10

4. A domain prototype is an aid for the incremental development of the ultimate

3.4 Component-based Development (CBD) – Manufacturers are adept in reusing and

AVCCE, Dept. of MCA – III Semester 11

In summary, in the initial sections, we have discussed generic software development

AVCCE, Dept. of MCA – III Semester 12

4. Object-Oriented Methodologies (OOM)

Operations - An operation is a behavior or function that an object can perform.

AVCCE, Dept. of MCA – III Semester 13

Components - A component is a collection of related classes that together provide a larger

Interfaces - An interface is a definition of a set of services provided by a component or by

1. The Booch Method

3. Beck and Cunningham produced class-responsibility-collaboration (CRC) cards

4. Wirfs-Brock, Wilkerson, and Wiener came up with responsibility-driven design

AVCCE, Dept. of MCA – III Semester 14

1. Rumbaugh et al.’s object modeling technique (OMT)

 Object model describes the structure of objects in a system: their identity,

 Dynamic model – OMT provides a detailed and comprehensive dynamic model,

AVCCE, Dept. of MCA – III Semester 15

4. An external entity is a source or destination of a data element; for example,