Unit-3 Oose

lOMoARcPSD|40484224
UNIT 3 Final COPY - notes
Object Oriented Software Engineering (Anna University)
Scan to open on Studocu
Studocu is not sponsored or endorsed by any college or university

Downloaded by VENKAT VIJAY MP ([email protected])
lOMoARcPSD|40484224
CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3
UNIT III SOFTWARE DESIGN

Software design – Design process – Design concepts – Coupling – Cohesion – Functional
independence – Design patterns – Model-view-controller – Publish-subscribe – Adapter –
Command– Strategy – Observer – Proxy – Facade – Architectural styles – Layered - Client Server -
Tiered - Pipe and filter- User Interface Design-Case Study.
PART A
1. What is meant by design?
 Design is a meaningful engineering representation of something that is to be built.
 It can be traced to a customer's requirements and at the same time assessed for quality
against a set of predefined criteria.
2. What are the four major areas of concern in design?

The four major areas of concern in design are:
 Data
 Architecture
 Interfaces
 Components
3. Define - Software design.

Software design is an iterative process through which requirements are translated into a
blueprint for constructing software.
4. Mention three characteristics for the evaluation of a good design.

The three characteristics for the evaluation of a good design. They are:
 The design must implement all of the explicit requirements contained in the
analysis model and must accommodate all the implicit requirements desired by
the customer. .
 The design must be an understandable guide for those who generate the code and
for those who test and subsequently support the software.
 The design should provide a complete picture of the software, addressing the data,
functional and behavioral domains from an implementation perspective.
5. Mention any eight software design principles. (Apr/May’12) (Or) List the principles of the
software design. Apr/May 2018.
The eight software design principles are:

1. A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or patterns,
PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 1

lOMoARcPSD|40484224
(2) is composed of components that exhibit good design characteristics , and

(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and
testing.
2. A design should be modular; that is, the software should be logically partitioned into elements or
subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and components.
4. A design should lead to data structures that are appropriate for the classes to be implemented and
are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning.
6. Explain the terms: Procedural abstraction, data abstraction and control abstraction.
 A "procedural abstraction" is a named sequence of instructions that has a specific and
limited function. Eg: The word "Open the door" implies walk to the door, reach out, grasp
knob, turn knob pull door etc.
 A "data abstraction" is a named collection of data that describes a data object. Eg : door.
The word door encompasses a set of attributes like door type, swing direction, opening
mechanism, etc.
 Control abstraction implies a program control mechanism without specifying internal
details. Eg : Synchronization semaphore.
7. Define - Software architecture.

Software architecture is defined as the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system.
8. Describe the properties that should be specified as part of the architectural design.
The properties are: .
 Structural properties:
It defines the components of a system and the manner in which those components are
packaged and interact with one another.
 Extra functional properties:
The design description should address how the design- architecture achieves requirements
for performance, capacity, reliability, security, adaptability and other system characteristics.
 Families of related systems:
The design should include the repeatable patterns commonly encountered in the design. The
design should have the ability to reuse architectural building blocks.

lOMoARcPSD|40484224
9. List all the five models in which the architectural design can be represented.
The architectural design can be represented using one or more-of a number of different
models namely,
 Structural model
 Framework model
 Dynamic model
 Process model
 Functional model
10. Define fan in and fan out.

 Fan-out is a measure of the number of modules that are direct1y controlled by another
module.
 Fan-in indicates how many modules directly control a given module
11. Explain the terms: Visibility and Connectivity.

 Visibility indicates the set of program components that may be invoked or used as data by a
given component, even when this is accomplished indirectly.
 Connectivity indicates the set of components that are directly invoked or used as a data by a
given component.
12. What are the benefits of horizontal partitioning?

The benefits of horizontal partitioning are:
 Software is easy to test
 Software is easy to maintain
 Propagation of fewer side effects
 Software is easy to extend.
13. What are the two types of structural partitioning? Explain.

The two types of structural partitioning are:
i. Horizontal partitioning
 Horizontal partitioning defines separate branches of the modular hierarchy for each major
program function.
ii. Vertical partitioning
 Vertical partitioning suggests that the control and work should be distributed top-down in
the program structure.
14. What is a data structure?

 Data structure is a representation of the logical relationship among individual elements of
data.

lOMoARcPSD|40484224
 It dictates the organization method of access, degree of associativity and processing

alternatives for information.
15. Explain the qualitative criteria for measuring independence.

Independence is measured using two qualitative criteria
 Cohesion
Cohesion is a measure of relative functional strength of a module.
 Coupling
Coupling is a measure of relative interdependence among modules.
16. Explain the following.

 Data coupling
Data coupling is exhibited when a simple data is passed between modules, i.e., a
one-to-one correspondence of items exist.
 Stamp coupling
Stamp coupling is found when a portion of a data structure is passed via a module
interface.
 Control coupling
when a 'control flag' .is passed between two modules.
17. Explain the following.
 External coupling
When modules are tied to an environment external to software
 Common coupling
When a number of modules reference a global data area, common coupling exists.
 Content coupling
When one module makes use of data or control information maintained within the
boundary of another module.
18. Mention any four design heuristics.

The four design heuristics are:
 Evaluate the "first iteration" of the program structure to reduce coupling and improve
cohesion.
 Attempt to minimize structures with high fan-out; strive for fan-in as depth increases.'
 Keep the scope of effect of a module within the scope of control of that module.
 Evaluate module interfaces to reduce complexity and redundancy and improve consistency.
19. With a neat diagram, describe the design model.

 Data design transforms information domain model created during analysis into data
structures that will be required to implement the software.
 Architectural design defines relationship between major structural elements of the
software.

lOMoARcPSD|40484224
 Interface design describes how the software communicates within itself, with systems that
inter-operate with it, and with humans who use it.
 Component level design transforms structural elements of the software architecture into a
procedural description of software components.
20. What is the purpose of a cross reference in the design specification?

The purpose of cross reference in design specification is :
 To establish that all requirements are satisfied by the software design.
 To indicate which components are critical to the implementation of specific requirements.
21. Why is software architecture important?

Software architecture is important for the following reasons:
 Representations of software architecture are an enabler for communication between all parties
interested in the development of a computer - based system.
 The architecture highlights early design decisions that will have a profound impact on all
software engineering work.
 Architecture constitutes a relatively, small, intellectually graspable model of how the system
is structured and how its components work together.
22. Mention any four principles applicable to data design.
The four principles applicable to data design are:
 The systematic analysis principles applied to function and behavior should also be
applied to data.
 All data structures and the operations to be performed on each should be identified.
 A data dictionary should be established and used to define both data and program
design.

lOMoARcPSD|40484224
 Low-level data design decisions should be deferred until late in the design process.
23. What is an architectural style?

The software built for computer-based systems exhibits one of manly architectural styles.
Each style describes a system category that encompasses,
 A set of components - that perform a function required by a system.
 A set of connectors that enable communication coordination and co-operation among
components.
 Constraints that define how components can be integrated to form the system. Semantic
models that enable the designer to understand the overall properties of a system by
analyzing the known properties of its constituent parts.
24. List any four architectural styles.

The four architectural styles are:
 Data - centered architectures
 Data - flow architectures
 Call and return architectures
 Object - oriented architectures.
25. Define - Transform Mapping.

Transform Mapping is a set of design steps that allows a Data Flow Diagram (DFD)
with transform flow characteristics to be mapped into a specific architectural style.
26. Explain - Transform Flow.

 Information enters the system along the paths that transform external data into internal form.
These paths are identified as incoming flow.
 At the kernel of the software, a transition occurs. Incoming data are passed through a
transform center and begin to move along paths that HOW lead "out" of the software.
 Data moving along these paths are called outgoing flow.
 The overall flow of data occurs in a sequential manner. When a segment of a data flow
diagram exhibits these characteristics, transform flow is present.
27. List out the design steps in transform mapping.

The design steps in transform mapping are
 Review the fundamental system model.
 Review and refine data flow diagrams for the software.
 Determine whether the DFD has transform or transaction flow characteristics.
 Isolate the transform center by specifying incoming and outgoing flow boundaries. .
 Perform "first - level factoring"
 Perform "second - level factoring"

lOMoARcPSD|40484224
 Refine the first iteration architectural using design heuristics for improved software
quality.
28. What happens after the architecture has been created?

After the architecture 'has been developed and refined, the following tasks must be
completed:
 A processing narrative must be developed for each module.
 An interface description is provided for each module.
 Local and global data structures are defined.
 All design restrictions and limitations are noted.
 A set of design reviews are conducted.
 Refinement is considered.
29. Explain User Interface Design.
User Interface Design creates an effective communication medium between a human and
a computer. Following a set of interface design principles, design identifies interface objects and
actions and then creates a screen layout that forms the basis of a user interface prototype.
30. What are the three rules that form the basis for the user interface design principles?
The three rules that form the basis for user interface design principles are:
 Place the user in control
 Reduce the user's memory load
 Make the interface consistent
31. How do we design interfaces that allow the user to maintain control?
The following design principles allow the user to maintain control:
 Define interaction modes in a way that does not force a user into unnecessary or
undesired actions.
 Provide for flexible interaction.
 Allow user interaction to be interruptible and undoable.
 Streamline interaction as skill levels advance and allow the interaction to be
customized.
 Hide technical internals from casual user.
 Design for direct interaction with objects that appear on the screen.
32. How do we design interfaces that reduce user's memory load?

The following design principles enable an interface to reduce user’s memory load:
 Reduce demand on short-term memory
 Enable meaningful defaults
 Define shortcuts that are intuitive
 The visual layout of the interface should be based on a real world metaphor.
 Disclose information in a progressive fashion.

lOMoARcPSD|40484224
33. List the user interface design principles, applicable to all user interface design.
The user interface design principles that are applicable all user interface design are:
 User familiarity
 Consistency
 Minimal surprise
 Recoverability
 User guidance
 User diversity
34. Name the two facilities that allow the users to recover from their mistakes.
The facilities that allow the users to recover from their mistakes are:
 Confirmation of destructive actions
 The provision of an undo facility
35. Classify the different forms of user interaction.

The different forms of user interaction can be classified as:
 Direct manipulation
 Menu selection
 Form fill-in
 Command language
 Natural language
36. What are the necessary factors that decide the presentation of information?
The necessary factors that decide the presentation of information are:
 Is the user interested in precise information or in the relationships between different data
values?
 How quickly do the information change? Should the change be indicated immediately to the
user?
 Should the user take some action in response to a change in information.
 Does the user need to interact with the displayed information via a direct manipulation
interface? v. Is the information to be displayed textual or numeric?
37. List any four guidelines for effective use of color in user interfaces.
The four guidelines for effective use of color in user interfaces are:
 Limit the number of colors used and be conservative how these are used
 Use color change to show a change in system status.
 Use color coding in a thoughtful and consistent way.
 Be careful about color pairings.

lOMoARcPSD|40484224
38. Name the three areas that provide user guidance.

The three areas that provides user guidance are:
 Messages produced by the system in response to user actions.
 The online help system.
 Documentation provided with the system.
39. List the design factors in message wording.

While designing error messages, the following factors must be taken into account namely,
 Context
 Experience
 Skill level
 Style
 Culture
40. Name the documents that must be delivered with the software system.
The documents that must be delivered with the software system are
 Functional description document
 Installation document
 Introductory manual
 Reference manual
 Administrator's manual
41. What is meant by interface evaluation? List any four usability attributes.
Interface evaluation is the process of assessing the ability of an interface and checking that
meets user requirements. An evaluation is done based on usability attributes.
Some of the usability attributes are
 Learn ability
 Speed of operation
 Robustness
 Adaptability
42. How do you apply modularization criteria for monolithic software? (May/Jun’12)
 Modular decomposability
 Modular composability
 Modular understability
 Modular continuity
 Modular protection
43. What are the design quality attributes “FURPS” meant? (May/Jun’12)
 F – functionality

lOMoARcPSD|40484224
 U – Usability
 R - Reliability
 P - Performance
 S – Supportability
44. How is the data warehouse different from a database? How are they similar?
Dissimilarities
S.No Data warehouse Database
1. OLAP OLTP
2. Data analysis and decision making Day to Day operations
3. Update driven Query driven
4. Star and snowflake schema design E-R diagram
5. Structure for corporate view of data Structure to suite departmental view of data
Similarities
 Both store data and information
 Database is a collection of tables and data warehouse is a collection of data from multiple
sources, stored under a unified schema residing on a single site.
45. If a module has logical cohesion, what kind of coupling is this module likely to have?
May/June 2016.
 When a module that performs a tasks that are l0ogically related with each other is called
logically cohesive.
 For such module content coupling can be suitable for coupling with other modules.
 The content coupling is a kind of coupling when one module makes use of data or control
information maintained in other module.
46. What is the need for architectural mapping using data flow? May/June 2016.
 Map the DFD in a program structure amenable to transaction processing.
 In this transaction flow, a single data item, called a transaction that triggers other flow along
one of many paths.
 It is characterized by data moving along an incoming path that converts external world
information.
47. What architectural styles are preferred for the following systems? Why? Nov/Dec
2016.
(a) Networking
(b) Web based systems
(c) Banking system

lOMoARcPSD|40484224
(a) Networking :Centralized: traditional client-server structure

– Vertical (or hierarchichal) organization of communication and control paths (as in
layered software architectures)
– Logical separation of functions into client (requesting process) and server
(responder)
• Decentralized: peer-to-peer
– Horizontal rather than hierarchical comm. and control
– Communication paths are less structured; symmetric functionality
• Hybrid: combine elements of C/S and P2P
– Edge-server systems
– Collaborative distributed systems.
• Classification of a system as centralized or decentralized refers to communication and
control organization, primarily.
(b) Web based systems: Data-Centered Architectures

Main purpose: data access and update
• Processes interact by reading and modifying data in some shared repository (active or
passive)
– Traditional data base (passive): responds to requests
– Blackboard system (active): clients solve problems collaboratively; system updates
clients when information changes.
• Another example: web-based distributed systems where communication is through web
services
(c)Banking system :Layered (software) Architecture for Client-Server Systems
• User-interface level: GUI’s (usually) for interacting with end users
• Processing level: data processing applications – the core functionality
• Data level: interacts with data base or file system
– Data usually is persistent; exists even if no client is accessing it
– File or database system
48. What UI design patterns are used for the following? Nov/Dec 2016.
a) Page layout
b) Tables
c) Navigation through menus and web pages
d) Shopping cart
What UI design patterns are used for the following? Apr/May 2017, Apr/May 2018
(a)Page layout.
(b)Navigation through menus and web pages.
Place the User in Control

lOMoARcPSD|40484224
 Define interaction modes in a way that does not force a user into unnecessary or
undesired actions.
 Provide for flexible interaction
 Allow user interaction to be interruptible and undoable.
 Streamline interaction as skill levels advance and allow the interaction to be
customized
 Hide technical internals from the casual user.
 Design for direct interaction with objects that appear on the screen
Reduce the User’s Memory Load
 Reduce demand on short-term memory
 Establish meaningful defaults
 Define shortcuts that are intuitive
 The visual layout of the interface should be based on a real-world metaphor
 Disclose information in a progressive fashion
Make the Interface Consistent
 Allow the user to put the current task into a meaningful context
 Maintain consistency across a family of applications
 If past interactive models have created user expectations, do not make changes
unless there is a compelling reason to do so.
UI design patterns for shopping cart
49. List down the steps to be followed for User Interface Design. (April/May 2015) (Or) What
are the golden rules for an interface design. (Nov/Dec 2015)
The Golden rules

Theo Mandel coins three golden rules:

lOMoARcPSD|40484224
1. Place the user in control.

2. Reduce the user’s memory load.
3. Make the interface consistent.
These golden rules actually form the basis for a set of user interface design principles that
guide this important aspect of software design.
50. Write a note on FURPS model of design quality. (Nov/Dec 2015) Write a note on FURPS
model. Nov/Dec 2017. Mention the design quality model proposed by Hewlett Packard.
Nov/Dec 2018
The FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
• Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the
predictability of the program.
• Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and
in addition, testability, compatibility, configurability the ease with which a system can be
installed, and the ease with which problems can be localized.
51. What is the purpose of a Petri Net? Apr/May 2017

 A Petri net is a particular kind of bipartite directed graphs populated by three types
of objects.
 These objects are places, transitions, and directed arcs.
 Directed arcs connect places to transitions or transitions to places.
 In its simplest form, a Petri net can be represented by a transition together with an
input place and an output place.
 This elementary net may be used to represent various aspects of the modeled
systems.
A Petri net is formally defined as a 5-tuple N = (P, T, I, O, M0), where

(1) P = {p1, p2, …, pm} is a finite set of places;
(2) T = {t1, t2, …, tn} is a finite set of transitions, P ∪ T ≠ ∅, and P ∩ T = ∅;
(3) I: P × T → N is an input function that defines directed arcs from places to
transitions, where N is a set of nonnegative integers;
(4) O: T × P → N is an output function that defines directed arcs from transitions
to places; and

lOMoARcPSD|40484224
(5) M0: P → N is the initial marking.
52. Draw the context flow graph of a ATM automation system. Nov/Dec 2017
53. Draw the zero level data flow diagram of an ATM system. Nov/Dec 2018
54. How does the Data Flow diagram help in design of software system? April/May 2019
DFD graphically representing the functions, or processes, which capture, manipulate, store,
and distribute data between a system and its environment and between components of a system.
The visual representation makes it a good communication tool between User and System designer.
55. Differentiate internal and external design. (April/May 2021)
Internal Design External design
Internal documentation is written in a program External documentation is written in a

as comments. place where people who need to use the
software can read about how to use the

lOMoARcPSD|40484224
software.
Internal documentation would be comments and External documentation would be things

remarks made by the programmer in the form of like flow charts, UML diagrams,
line comments requirements documents, design
documents etc.
Internal Documentation is created within the External Documentation is created by

programming department and shows the design the user and Programmer/System
and implementation of the project (flow charts, Analyst.
UML diagrams, design documents, etc.).
56. List out the various types of cohesion and coupling. (April/May 2021)
Types of cohesion Types of Coupling

1. Functional Cohesion 1. Content coupling
2. Sequential Cohesion 2. Common coupling
3. Communicational Cohesion 3. Control coupling
4. Procedural Cohesion 4. Stamp coupling
5. Temporal Cohesion 5. Data coupling
6. Logical Cohesion 6. External coupling
7. Coincidental Cohesion 7. Type use coupling
8. Inclusion or import coupling
9. Routine call coupling
57. Define patterns.
A pattern is a named problem/solution pair that can be applied in new context, with
advice on how to apply it in novel situations and discussion of its trade-offs.
58. Give the GRASP Patterns used for object design. (NOV/DEC 2021)
The following sections present the first five GRASP patterns:
 Information Expert
 Creator
 High Cohesion
 Low Coupling
 Controller
59. What are the two responsibilities?

The responsibilities are of the following two types: doing and knowing.
 Doing responsibilities of an object include:

lOMoARcPSD|40484224
 doing something itself, such as creating an object or doing a calculation

 initiating action in other objects
 controlling and coordinating activities in other objects
 Knowing responsibilities of an object include:
 knowing about private encapsulated data
 knowing about related objects
 knowing about things it can derive or calculate
60. List out some scenarios that illustrate varying degrees of functional cohesion.
 Very low cohesion
 Low cohesion
 High cohesion
 Moderate cohesion
61. What are the advantages of Factory objects?

 Separate the responsibility of complex creation into cohesive helper objects.
 Hide potentially complex creation logic.
 Allow introduction of performance-enhancing memory management strategies,
such as object caching or recycling.
62. What is meant by Abstract Class Abstract Factory?

A common variation on Abstract Factory is to create an abstract class factory that is
accessed using the Singleton pattern, reads from a system property to decide which of its
subclass factories to create, and then returns the appropriate subclass instance. This is used, for
example, in the Java libraries with the java.awt.Toolkit class, which is an abstract class abstract
factory for creating families of GUI widgets for different operating system and GUI subsystems.
63. Define GRASP or What is GRASP? (May-June’13) (APR/MAY 2022)

GRASP (general Responsibility Assignment software Patterns)
The Grasp principles or patterns are learning aid to help us to understand essential object
design and apply design and apply design reasoning in a methodical, rational, explainable way.
GRASP is used as a tool to help master the basics of OOD and understanding
responsibility assignment in object design.
64. What is Information Expert?

Information Expert is a principle used to determine where to delegate responsibilities.
These responsibilities include methods, computed fields and so on. Using the principle of
Information Expert a general approach to assigning responsibilities is to look at a given
responsibility, determine the information needed to fulfill it, and then determine where that
information is stored. Information Expert will lead to placing the responsibility on the class with
the most information required to fulfill it.

lOMoARcPSD|40484224
65. What are the benefits of low Coupling?

 Low Coupling is Not affected by changes in other components.
 Simple to understand in isolation.
 Convenient to reuse
66. What is Controller?

The Controller pattern assigns the responsibility of dealing with system events to a non-
UI class that represents the overall system or a use case scenario. A Controller object is a non-
user interface object responsible for receiving or handling a system event.
67. Define Low Coupling.

Low Coupling is an evaluative pattern, which dictates how to assign responsibilities to
support:
 low dependency between classes;
 low impact in a class of changes in other classes;
 high reuse potential;
68. Define High Cohesion. (NOV / DEC 2012) (NOV / DEC 2021)
High Cohesion is an evaluative pattern that attempts to keep objects appropriately
focused, manageable and understandable. High cohesion is generally used in support of Low
Coupling. High cohesion means that the responsibilities of a given element are strongly related
and highly focused. Breaking programs into classes and subsystems is an example of activities
that increase the cohesive properties of a system.
69. When patterns is said to be a Good Patterns? (May-June’13) (May-June’12) (Nov-Dec’11)

A pattern is said to be good pattern if it is a named and well known problem/solution
pair that can be applied in new context, with advice on how to apply it in novel situation and
discussion of its trade-offs, implementation, variations, etc.
70. Why patterns are named? (May-June’12) (Nov-Dec’11)

Advantages of Naming a Pattern: Patterns are named so that the solution they
encompass can be communicated and discussed with clarity.
Pattern name establish a common understanding of the key characteristics of their
implementation.
Eg: Bubble Sort
Abstract Factory
71. How to define a new pattern?
New pattern is an oxymoron: New Pattern should be considered as an Oxymoron if it
describes a new idea. Since patterns attempt to codify existing tried-and-true knowledge, idioms

lOMoARcPSD|40484224
and principles, the more honed, old and widely used. New patterns should be considered as an
oxymoron (contradiction to original or opposite to real).
72. Define GoF patterns.

GoF Design Patterns (Gang-Of-Four Design Pattern ):
Design Pattern: Elements of Reusable object oriented software is a software
engineering book describing recurring solution to common problem in software design. The
book’s authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a
foreword by Grady Booch. They are often referred to as Gang of Four or GoF.
73. Define Façade Controller.

Façade Controllers are suitable when there are not “too many” system events, or when
the User Interface (UI) cannot redirect system event messages to alternating controllers, such as
in a messages processing system.
74. What are the Benefits of Controller?

Increased potential for reuse and pluggable interfaces-This ensures that application logic
is not handled in the interface layer.
An application as controller design reduces the opportunity to reuse logic in future
applications.
But delegating a system operation responsibility to a controller supports the reuse of the
logic in future applications.
75. What is a Bloated Controller?

Poorly designed, a controller class will have low cohesion unfocused and handling too
many areas of responsibility this is called a bloated controller. Signs of bloating are there is only
a single controller class receiving all system events in the system and there are many of them.
This sometimes happen if a facade controller is chosen.
76. Define Singleton.

Singleton Pattern is a design pattern used to implement the mathematical concept of
a singleton, by restricting the instantiation of a class to one object.
In other words, singleton is a class which only allows a single instance of itself to be
created and usually give simple access to that instance.
77. Define Factory.

Factory Pattern: Factory Pattern is a design pattern to implement the concept of factories
This Pattern is not a GoF Design Pattern but a GoF Abstract Factory Pattern. This is called
as Simple Factory or Concrete Factory.
78. What are the advantages of Factory Objects?


lOMoARcPSD|40484224
Advantages of Factory objects:

 Separate the responsibility of complex into cohesive helper object.
 Allow introduction of performance-enhancing memory management strategies, such
as object caching or recycling.
79. What is singleton pattern?

The singleton pattern is a design pattern used to implement the mathematical concept of
a singleton, by restricting the instantiation of a class to one object. This is useful when exactly
one object is needed to coordinate actions across the system.
80. What is adapter pattern?

The adapter pattern is a design pattern that translates one interface for a class into a
compatible interface. An adapter allows classes to work together that normally could not
because of incompatible interfaces, by providing its interface to clients while using the original
interface. The adapter is also responsible for transforming data into appropriate forms.
81. What is Facade Pattern?

A facade is an object that provides a simplified interface to a larger body of code, such
as a class library. A facade can:
• make a software library easier to use, understand and test, since the facade has convenient
methods for common tasks;
• make code that uses the library more readable, for the same reason;
• reduce dependencies of outside code on the inner workings of a library, since most code
uses the facade, thus allowing more flexibility in developing the system;
• Wrap a poorly-designed collection of APIs with a single well-designed API (as per task
needs).
82. Define Observer Pattern.

Observer Pattern is a software design pattern in which an object called the subject,
maintains a list of its dependents, called observers, and notifies them automatically of any state
changes usually by calling one of their methods. It is mainly used to implement distributed
event handling systems.
83. What is Bridge?

The bridge pattern is a design pattern used in software engineering which is meant to "decouple
an abstraction from its implementation so that the two can vary independently". The bridge uses
encapsulation, aggregation, and can use inheritance to separate responsibilities into different
classes.
84. How to map designs to code? (or) What are the steps for mapping designs to code?

lOMoARcPSD|40484224
(NOV/DEC 2015) (MAY/JUNE 2016)

 Implement i.e., write source code in an object oriented language for
 Class and Interface Definitions.
 Method Definitions.
 Each class in design is implemented by coding it in a programming language.
PART - B
1. Explain in detail about Software design.
 Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software.
 Initially, the blueprint depicts a holistic view of software.

lOMoARcPSD|40484224
 That is, the design is represented at a high level of abstraction— a level that can be directly
traced to the specific system objective and more detailed data, functional, and behavioral
requirements.
Software Quality Guidelines and Attributes
Throughout the design process, the quality of the evolving design is assessed with a series of
technical reviews. Mc Glaughlin suggests three characteristics that serve as a guide for the
evaluation of a good design:
• The design must implement all of the explicit requirements contained in the requirements
model, and it must accommodate all of the implicit requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who generate code and for
those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.
Each of these characteristics is actually a goal of the design process.

Quality Guidelines
1. A design should exhibit an architecture that
(1) Has been created using recognizable architectural styles or patterns,
(2) Is composed of components that exhibit good design characteristics, and
(3) Can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing.
2. A design should be modular; that is, the software should be logically partitioned into
elements or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components.
4. A design should lead to data structures that are appropriate for the classes to be
implemented and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.

lOMoARcPSD|40484224
7. A design should be derived using a repeatable method that is driven by information

obtained during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its
meaning.
They are achieved through the application of fundamental design principles, systematic
methodology, and thorough review.
Quality Attributes.
Hewlett-Packard developed a set of software quality attributes that has been given the acronym
FURPS—functionality, usability, reliability, performance, and supportability. The FURPS quality
attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
• Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the
predictability of the program.
• Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and
in addition, testability, compatibility, configurability the ease with which a system can be
installed, and the ease with which problems can be localized.
`
The Evolution of Software Design
 The evolution of software design is a continuing process that has now spanned almost six
decades.
 Early design work concentrated on criteria for the development of modular programs and
methods for refining software structures in a top-down manner.
 Procedural aspects of design definition evolved into a philosophy called structured
programming.

lOMoARcPSD|40484224
 Later work proposed methods for the translation of data flow or data structure into a design
definition.
 Newer design approaches proposed an object-oriented approach to design derivation. More
recent emphasis in software design has been on software architecture and the design patterns
that can be used to implement software architectures and lower levels of design abstractions.
 Growing emphasis on aspect-oriented methods, model-driven development, and test-driven
development emphasize techniques for achieving more effective modularity and
architectural structure in the designs that are created.
All of these methods have a number of common characteristics:
(1) A mechanism for the translation of the requirements model into a design representation,
(2) A notation for representing functional components and their interfaces,
(3) Heuristics for refinement and partitioning, and
(4) Guidelines for quality assessment.
2. Explain about design process.

Definition:
The design phase of software development deals with transforming the customer requirements as
described in the SRS documents into a form implementable using a programming language. The
software design process can be divided into the following three levels or phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Elements of a system:
 Architecture: This is the conceptual model that defines the structure, behavior, and views
of a system. We can use flowcharts to represent and illustrate the architecture. (Refer figure
3.1)
 Modules: These are the components that handle one specific task in a system. A
combination of the modules makes up the system.
 Components: This provides a particular function or group of related functions. They are
made up of modules.

lOMoARcPSD|40484224
 Interfaces: This is the shared boundary across which the components of a system exchange
information and relate.
 Data: This is the management of the information and data flow.
Figure 3.1 – Software Design process
Interface Design:
Interface design is the specification of the interaction between a system and its
environments. This phase proceeds at a high level of abstraction with respect to the inner workings
of the system.
 i.e., during interface design, the internal of the systems are completely ignored, and
the system is treated ad black box.

lOMoARcPSD|40484224
 Attention is focused on the dialogue between the target system and the users,
devices, and other systems with which it interacts.
 The design problem statement produced during the problem analysis step should
identify the people, other systems, and devices which are collectively called agents.
 Interface design should include the following details:
 Precise description of events in the environment, or messages from agents to which
the system must respond.
 Precise description of the events or messages that the system must produce.
 Specification on the data, and the formats of the data coming into and going out of
the system.
 Specification of the ordering and timing relationships between incoming events or
messages, and outgoing events or outputs.
Architectural Design:
Architectural design is the specification of the major components of a system, their

responsibilities, properties, interfaces, and the relationships and interactions between them. In
architectural design, the overall structure of the system is chosen, but the internal details of major
components are ignored.
Issues in architectural design includes:
 Gross decomposition of the systems into major components.

 Allocation of functional responsibilities to components.
 Component Interfaces
 Component scaling and performance properties, resource consumption properties, reliability
properties, and so forth.
 Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.
Detailed Design:

lOMoARcPSD|40484224
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
The detailed design may include:
 Decomposition of major system components into program units.

 Allocation of functional responsibilities to units.
 User interfaces
 Unit states and state changes
 Data and control interaction between units
 Data packaging and implementation, including issues of scope and visibility of program
elements
 Algorithms and data structures
3. Write neatly the basis of Design Concepts. (Or) What is modularity? State its
importance and explain coupling and cohesion. (or) Discuss about the design concepts
in a software development process. (or) List and explain any five fundamental
software design concepts.
A set of fundamental software design concepts has evolved over the history of software
engineering. Although the degree of interest in each concept has varied over the years, each has
stood the test of time. Each provides the software designer with a foundation from which more
sophisticated design methods can be applied.
 Each helps you answer the following questions:

• What criteria can be used to partition software into individual components?
• How function or data is structure detail separated from a conceptual representation
of the software?
• What uniform criteria define the technical quality of a software design?
Abstraction
 When you consider a modular solution to any problem, many levels of abstraction can be
posed.
 At the highest level of abstraction , a solution is stated in broad terms using the language of
the problem environment.

lOMoARcPSD|40484224
 At lower levels of abstraction, a more detailed description of the solution is provided.

 Problem-oriented terminology is coupled with implementation-oriented terminology in an
effort to state a solution. Finally, at the lowest level of abstraction, the solution is stated in a
manner that can be directly implemented.
Different levels of abstraction
 A procedural abstraction refers to a sequence of instructions that have a specific and
limited function. The name of a procedural abstraction implies these functions, but specific
details are suppressed.
 An example of a procedural abstraction would be the word open for a door. Open
implies a long sequence of procedural steps (e.g., walk to the door, reach out and
grasp knob, turn knob and pull door, step away from moving door, etc.).
 A data abstraction is a named collection of data that describes a data object. In the context
of the procedural abstraction open, we can define a data abstraction called door.
 Like any data object, the data abstraction for door would encompass a set of
attributes that describe the door (e.g., door type, swing direction, opening
mechanism, weight, dimensions). It follows that the procedural abstraction open
would make use of information contained in the attributes of the data abstraction
door.
Architecture
 Software architecture alludes to “the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system”.
 In its simplest form, architecture is the structure or organization of program components
(modules), the manner in which these components interact, and the structure of data that are
used by the components.
 A set of architectural patterns enables a software engineer to solve common design
problems. A set of properties that should be specified as part of an architectural design:
Structural properties
 This aspect of the architectural design representation defines the components of a system
(e.g., modules, objects, filters) and the manner in which those components are packaged and
interact with one another.

lOMoARcPSD|40484224
 For example, objects are packaged to encapsulate both data and the processing that
manipulates the data and interact via the invocation of methods.
Extra-functional properties
 The architectural design description should address how the design architecture achieves
requirements for performance, capacity, reliability, security, adaptability, and other system
characteristics.
Families of related systems
 The architectural design should draw upon repeatable patterns that are commonly
encountered in the design of families of similar systems. In essence, the design should have
the ability to reuse architectural building blocks. Given the specification of these properties,
the architectural design can be represented using one or more of a number of different
models.
 Structural models represent architecture as an organized collection of
program components.
 Framework models increase the level of design abstraction by attempting to
identify repeatable architectural design frameworks that are encountered in
similar types of applications.
 Dynamic models address the behavioral aspects of the program architecture,
indicating how the structure or system configuration may change as a
function of external events.
 Process models focus on the design of the business or technical process that
the system must accommodate.
 Finally, functional models can be used to represent the functional hierarchy
of a system.
A number of different architectural description languages (ADLs) have been developed to
represent these models.
Patterns
 Brad Appleton defines a design pattern in the following manner: “A pattern is a named
nugget of insight which conveys the essence of a proven solution to a recurring problem
within a certain context amidst competing concerns”.

lOMoARcPSD|40484224
 Stated in another way, a design pattern describes a design structure that solves a particular
design problem within a specific context and amid “forces” that may have an impact on the
manner in which the pattern is applied and used.
 The intent of each design pattern is to provide a description that enables a designer to
determine
(1) Whether the pattern is applicable to the current work,
(2) Whether the pattern can be reused (hence, saving design time), and
(3) Whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern.
Separation of Concerns
 Separation of concerns is a design concept that suggests that any complex problem can be
more easily handled if it is subdivided into pieces that can each be solved and/or optimized
independently.
 A concern is a feature or behavior that is specified as part of the requirements model for the
software. By separating concerns into smaller, and therefore more manageable pieces, a
problem takes less effort and time to solve.
 Separation of concerns is manifested in other related design concepts:
i) Modularity,
ii) Information hiding,
iii) Functional independence,
iv) Refinement and
v) Aspects.
i) Modularity
 Modularity is the most common manifestation of separation of concerns.
 Software is divided into separately named and addressable components, sometimes called
modules, which are integrated to satisfy problem requirements.
 It has been stated that “modularity is the single attribute of software that allows a program to
be intellectually manageable”.
 Monolithic software (i.e., a large program composed of a single module) cannot be easily
grasped by a software engineer. The number of control paths, span of reference, number of

lOMoARcPSD|40484224
variables, and overall complexity would make understanding close to impossible. In almost
all instances, you should break the design into many modules, hoping to make
understanding easier and, as a consequence, reduce the cost required to build the software.
 Referring to Figure 3.2, the effort (cost) to develop an individual software module does
decrease as the total number of modules increases. Given the same set of requirements,
more modules means smaller individual size. However, as the number of modules grows,
the effort (cost) associated with integrating the modules also grow. These characteristics
lead to a total cost or effort curve shown in the figure. There is a number, M, of modules that
would result in minimum development cost, but we do not have the necessary sophistication
to predict M with assurance.
Figure 3.2 – Modularity and software cost

Benefits:
 Development can be more easily planned
 Software increments can be defined and delivered
 Changes can be more easily accommodated
 Testing and debugging can be conducted more efficiently, and
 Long-term maintenance can be conducted without serious side effects.
ii) Information Hiding

lOMoARcPSD|40484224
 The principle of information hiding suggests that modules be “characterized by design

decisions that (each) hides from all others.”
 In other words, modules should be specified and designed so that information (algorithms
and data) contained within a module is inaccessible to other modules that have no need for
such information.
 Hiding implies that effective modularity can be achieved by defining a set of independent
modules that communicate with one another only that information necessary to achieve
software function.
 Abstraction helps to define the procedural (or informational) entities that make up the
software. Hiding defines and enforces access constraints to both procedural detail within a
module and any local data structure used by the module.
Benefits:
 Provides the greatest benefits when modifications are required during testing and later
during software maintenance.
 Because most data and procedural detail are hidden from other parts of the software,
inadvertent errors introduced during modification are less likely to propagate to other
locations within the software.
iii) Functional Independence
 The concept of functional independence is a direct outgrowth of separation of concerns,
modularity, and the concepts of abstraction and information hiding.
 Functional independence is achieved by developing modules with “singleminded” function
and an “aversion” to excessive interaction with other modules.
 Stated another way, you should design software so that each module addresses a specific
subset of requirements and has a simple interface when viewed from other parts of the
program structure.
Benefits
 Independent modules, is easier to develop because function can be compartmentalized and
interfaces are simplified (consider the ramifications when development is conducted by a
team).

lOMoARcPSD|40484224
 Independent modules are easier to maintain (and test) because secondary effects caused by
design or code modification are limited, error propagation is reduced, and reusable modules
are possible.
 To summarize, functional independence is a key to good design, and design is the key to
software quality.
 Independence is assessed using two qualitative criteria:
 Cohesion
 Coupling
 Cohesion is an indication of the relative functional strength of a module. Cohesion is a

natural extension of the information-hiding concept. A cohesive module performs a single
task, requiring little interaction with other components in other parts of a program.
 Stated simply, a cohesive module should (ideally) do just one thing. Although you should
always strive for high cohesion (i.e., single-mindedness), it is often necessary and advisable
to have a software component perform multiple functions.
 Coupling is an indication of the relative interdependence among modules. Coupling is an
indication of interconnection among modules in a software structure. Coupling depends on
the interface complexity between modules, the point at which entry or reference is made to a
module, and what data pass across the interface.
 In software design, you should strive for the lowest possible coupling. Simple connectivity
among modules results in software that is easier to understand and less prone to a “ripple
effect”, caused when errors occur at one location and propagates throughout a system.
iv) Refinement
 Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth . A
program is developed by successively refining levels of procedural detail.
 A hierarchy is developed by decomposing a macroscopic statement of function (a
procedural abstraction) in a stepwise fashion until programming language statements are
reached.
 Refinement is actually a process of elaboration. You begin with a statement of function (or
description of information) that is defined at a high level of abstraction. That is, the

lOMoARcPSD|40484224
statement describes function or information conceptually but provides no information about

the internal workings of the function or the internal structure of the information.
 Abstraction enables you to specify procedure and data internally but suppress the need
for “outsiders” to have knowledge of low-level details.
 Refinement helps you to reveal low-level details as design progresses. Both concepts allow
you to create a complete design model as the design evolves.
v) Aspects
 An aspect is a representation of a crosscutting concern. Therefore, the design
representation, B*, of the requirement a registered user must be validated prior to using
SafeHomeAssured.com, is an aspect of the SafeHome WebApp.
Refactoring
 An important design activity suggested for many agile methods, refactoring is a
reorganization technique that simplifies the design (or code) of a component without
changing its function or behavior.
 Fowler defines refactoring in the following manner: “Refactoring is the process of
changing a software system in such a way that it does not alter the external behavior of
the code [design] yet improves its internal structure.”
 When software is refactored, the existing design is examined for redundancy, unused design
elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data
structures, or any other design failure that can be corrected to yield a better design.
Object-Oriented Design Concepts
The object-oriented (OO) paradigm is widely used in modern software engineering. OO
design concepts such as classes and objects, inheritance, messages, and polymorphism, among
others.
4. Explain in detail about design classes.

Design Classes
 The requirements model defines a set of analysis classes. Each describes some element of
the problem domain, focusing on aspects of the problem that are user visible. The level of
abstraction of an analysis class is relatively high.

lOMoARcPSD|40484224
Five different types of design classes, each representing a different layer of the design architecture,
can be developed:
 User interface classes define all abstractions that are necessary for human computer
interaction (HCI). In many cases, HCI occurs within the context of a metaphor (e.g., a
checkbook, an order form, a fax machine), and the design classes for the interface may be
visual representations of the elements of the metaphor.
 Business domain classes are often refinements of the analysis classes defined earlier. The
classes identify the attributes and services (methods) that are required to implement some
element of the business domain.
 Process classes implement lower-level business abstractions required to fully manage the
business domain classes.
 Persistent classes represent data stores (e.g., a database) that will persist beyond the
execution of the software.
 System classes implement software management and control functions that enable the
system to operate and communicate within its computing environment and with the outside
world.
As the architecture forms, the level of abstraction is reduced as each analysis class is transformed
into a design representation. Design classes present significantly more technical detail as a guide for
implementation.
The four characteristics of a well-formed design class are:
 Complete and sufficient. A design class should be the complete encapsulation of all
attributes and methods that can reasonably be expected (based on a knowledgeable
interpretation of the class name) to exist for the class.
 Primitiveness. Methods associated with a design class should be focused on accomplishing
one service for the class. Once the service has been implemented with a method, the class
should not provide another way to accomplish the same thing
 High cohesion. A cohesive design class has a small, focused set of responsibilities and
single-mindedly applies attributes and methods to implement those responsibilities.

lOMoARcPSD|40484224
 Low coupling. Within the design model, it is necessary for design classes to collaborate
with one another. However, collaboration should be kept to an acceptable minimum. If a
design model is highly coupled (all design classes collaborate with all other design classes),
the system is difficult to implement, to test, and to maintain over time.
5. Explain in detail about Coupling and Cohesion with its types.
Coupling
Coupling is a qualitative measure of the degree to which classes are connected to one
another. As classes (and components) become more interdependent, coupling increases. An
important objective in component-level design is to keep coupling as low as is possible. Class
coupling can manifest itself in a variety of ways. Lethbridge and Laganiére [Let01] define the
following coupling categories:
 Content coupling. Occurs when one component “surreptitiously modifies data that is
internal to another component” [Let01]. This violates information hiding—a basic design
concept.
 Common coupling. Occurs when a number of components all make use of a global
variable. Although this is sometimes necessary (e.g., for establishing default values that are
applicable throughout an application), common coupling can lead to uncontrolled error
propagation and unforeseen side effects when changes are made.
 Control coupling. Occurs when operation A() invokes operation B() and passes a control
flag to B. The control flag then “directs” logical flow within B. The problem with this form
of coupling is that an unrelated change in B can result in the necessity to change the
meaning of the control flag that A passes. If this is overlooked, an error will result.
 Stamp coupling. Occurs when ClassB is declared as a type for an argument of an operation
of ClassA. Because ClassB is now a part of the definition of ClassA, modifying the system
becomes more complex.
 Data coupling. Occurs when operations pass long strings of data arguments. The
“bandwidth” of communication between classes and components grows and the complexity
of the interface increases. Testing and maintenance are more difficult.

lOMoARcPSD|40484224
 Routine call coupling. Occurs when one operation invokes another. This level of coupling
is common and is often quite necessary. However, it does increase the connectedness of a
system.
 Type use coupling. Occurs when component A uses a data type defined in component B
(e.g., this occurs whenever “a class declares an instance variable or a local variable as
having another class for its type” [Let01]). If the type definition changes, every component
that uses the definition must also change.
 Inclusion or import coupling. Occurs when component A imports or includes a package or
the content of component B.
 External coupling. Occurs when a component communicates or collaborates with
infrastructure components (e.g., operating system functions, database capability,
telecommunication functions). Although this type of coupling is necessary, it should be
limited to a small number of components or classes within a system.
Software must communicate internally and externally. Therefore, coupling is a fact of life.
However, the designer should work to reduce coupling whenever possible and understand the
ramifications of high coupling when it cannot be avoided.
Cohesion
Cohesion as the “single-mindedness” of a component. Within the context of component-level
design for object-oriented systems, cohesion implies that a component or class encapsulates only
attributes and operations that are closely related to one another and to the class or component itself.
Lethbridge and Laganiére define a number of different types of cohesion (listed in order of the level
of the cohesion):
 Functional. Exhibited primarily by operations, this level of cohesion occurs when a
component performs a targeted computation and then returns a result.
 Layer. Exhibited by packages, components, and classes, this type of cohesion occurs when
a higher layer accesses the services of a lower layer, but lower layers do not access higher
layers. Consider, for example, the SafeHome security function requirement to make an
outgoing phone call if an alarm is sensed. It might be possible to define a set of layered
packages as shown in Figure 3.3. The shaded packages contain infrastructure components.
Access is from the control panel package downward.

lOMoARcPSD|40484224
 Communicational. All operations that access the same data are defined within one class. In
general, such classes focus solely on the data in question, accessing and storing it.
Classes and components that exhibit functional, layer, and communicational cohesion are
relatively easy to implement, test, and maintain. You should strive to achieve these levels of
cohesion whenever possible. It is important to note, however, that pragmatic design and
implementation issues sometimes force you to opt for lower levels of cohesion.
Figure 3.3 – Layer Cohesion
6. What is functional independence in software engineering?

 Functional independence in software engineering means that when a module focuses on a
single task, it should be able to accomplish it with very little interaction with other modules.
 In software engineering, if a module is functionally independent of other module then
it means it has high cohesion and low coupling.
 Functional independence is essential for good software design.
Example of functional independence
 We will take an example of simple college level project to explain concept of functional
independence.
 Suppose you and your friends are asked to work on a calculator project as a team. Here we
need to develop each calculator functionality in form of modules taking two user inputs.

lOMoARcPSD|40484224
o So our modules are additionModule, subtractionModule, divisionModule,

multiplicationModule. Each one of you pick up one module for development
purpose.
o Before you enter into development phase, you and your team needs to make sure to
design the project in such a way that each of the module that you develop
individually should be able to perform its assigned task without requiring much or
no interaction with your friends module.
o What I intend to say is, if you are working on additionModule then your module
should be able to independently perform addition operation on recieving user input.
It should not require to make any interaction with other modules like
subtractionModule, multiplicationModule or etc.
This is actually the concept of having module as functional independence of other modules. There
are advantages of functional independence in software engineering which we are going to discuss
next.
Advantage of functional independence
Advantages of functional independence are given below:
 Error isolation
 When a module is functionally independent then it performs most of its task
independently without interacting with other modules much. This reduces the chances of
error getting propagated to other modules. This helps in easily isolating and tracing the
error.
 Module reusability
 A functionally independent module performs some well defined and specific task. So it
becomes easy to reuse such modules in different program requiring same functionality.
 Understandability
 A functionally independent module is less complex so easy to understand. Since such
modules are less interaction with other modules so can be understood in isolation.
7. Explain about Design patterns in software design.
 Definition:

lOMoARcPSD|40484224
Design patterns represent the best practices used by experienced object-oriented software
developers. Design patterns are solutions to general problems that software developers faced during
software development. These solutions were obtained by trial and error by numerous software
developers over quite a substantial period of time.
 What is Gang of Four (GOF)?
 In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
published a book titled Design Patterns - Elements of Reusable Object-Oriented
Software which initiated the concept of Design Pattern in Software development.
 These authors are collectively known as Gang of Four (GOF). According to these authors
design patterns are primarily based on the following principles of object orientated design.
 Program to an interface not an implementation
 Favor object composition over inheritance
Usage of Design Pattern
 Design Patterns have two main usages in software development.
Common platform for developers
 Design patterns provide a standard terminology and are specific to particular scenario.
For example, a singleton design pattern signifies use of single object so all developers
familiar with single design pattern will make use of single object and they can tell each
other that program is following a singleton pattern.
Best Practices
 Design patterns have been evolved over a long period of time and they provide best
solutions to certain problems faced during software development. Learning these patterns
helps unexperienced developers to learn software design in an easy and faster way.
Types of Design Patterns:

1. Creational Patterns
2. Structural Patterns
3. Behavioral Patterns
4. J2EE Patterns
1. Creational Patterns:

lOMoARcPSD|40484224
 These design patterns provide a way to create objects while hiding the creation logic,
rather than instantiating objects directly using new operator. This gives program more
flexibility in deciding which objects need to be created for a given use case.
2. Structural Patterns
 These design patterns concern class and object composition. Concept of inheritance is
used to compose interfaces and define ways to compose objects to obtain new
functionalities.
3. Behavioral Patterns
 These design patterns are specifically concerned with communication between objects.
4. J2EE Patterns
 These design patterns are specifically concerned with the presentation tier. These
patterns are identified by Sun Java Center.
8. Explain in detail about Model-view-controller (MVC).

 The Model-View-Controller (MVC) is a well-known design pattern in the web development
field. It is way to organize our code.
 It specifies that a program or application shall consist of data model, presentation information
and control information.
 The MVC pattern needs all these components to be separated as different objects.
What is MVC architecture?
 The model designs based on the MVC architecture follow MVC design pattern. The
application logic is separated from the user interface while designing the software using
model designs.
 The MVC pattern architecture(Refer Figure 3.4) consists of three layers:

o Model: It represents the business layer of application. It is an object to carry the data
that can also contain the logic to update controller if data is changed.
o View: It represents the presentation layer of application. It is used to visualize the
data that the model contains.

lOMoARcPSD|40484224
o Controller: It works on both the model and view. It is used to manage the flow of
application, i.e. data flow in the model object and to update the view whenever data
is changed.
Figure 3.4 – MVC Architecture

1. A client (browser) sends a request to the controller on the server side, for a page.
2. The controller then calls the model. It gathers the requested data.
3. Then the controller transfers the data retrieved to the view layer.
4. Now the result is sent back to the browser (client) by the view.
 In the Model/View/Controller (MVC) architectural style (Fig.3.5), subsystems are classified into
three different types: model subsystems maintain domain knowledge, view subsystems display it
to the user, and controller subsystems manage the sequence of interactions with the user.
 The model subsystems are developed such that they do not depend on any view or controller
subsystem. Changes in their state are propagated to the view subsystem via a subscribe/notify
protocol. The MVC is a special case of the repository where Model implements the central data
structure and control objects dictate the control flow.

lOMoARcPSD|40484224
Figure 3.5 - Model/View/Controller architectural style (UML class diagram). The Controller
gathers input from the user and sends messages to the Model. The Model maintains the central data
structure. The Views display the Model and are notified (via a subscribe/notify protocol) whenever
the Model is changed.
 For example, Figures 3.6 and 3.7 illustrate the sequence of events that occur in an MVC
architectural style. Figure 6-16 displays two views of a file system. The bottom window lists the
content of the Comp-Based Software Engineering folder, including the file 9DesignPatterns2.ppt.
The top window displays information about this file.
 The name of the file 9DesignPatterns2.ppt appears in three places: in both windows and in the
title of the top window. Assume now that we change the name of the file to 9DesignPatterns.ppt.
Figure 3.7 shows the sequence of events:
1. The InfoView and the FolderView both subscribe for changes to the File models they
display (when they are created).
2. The user types the new name of the file.
3. The Controller, the object responsible for interacting with the user during file name
changes, sends a request to the Model.
4. The Model changes the file name and notifies all subscribers of the change.
5. Both InfoView and FolderView are updated, so the user sees a consistent change

lOMoARcPSD|40484224
Figure 3.6 - An example of MVC architectural style. The “model” is the filename
9DesignPAtterns2.ppt. One “view” is a window titled CBSE, which displays the contents of a
folder containing the file 9DesignPatterns2.ppt. The other “view” is window called
9DesignPatterns2.ppt Info, which displays information related to the file. If the file name is
changed, both views are updated by the “controller.”

lOMoARcPSD|40484224
Figure 3.7 Sequence of events in the Model/View/Control architectural style (UML

communication diagram).
 The subscription and notification functionality associated with this sequence of events is usually
realized with an Observer design pattern (see Section A.7). The Observer design pattern allows
the Model and the View objects to be further decoupled by removing direct dependencies from
the Model to the View. For more details, the reader is referred to [Gamma et al., 1994] and to
Section A.7.
 The rationale between the separation of Model, View, and Controller is that user interfaces, i.e.,
the View and the Controller, are much more often subject to change than is domain knowledge,
i.e., the Model. Moreover, by removing any dependency from the Model on the View with the
subscription/notification protocol, changes in the views (user interfaces) do not have any effect on
the model subsystems.
 In the example of Figure 3.6, we could add a Unix-style shell view of the file system without
having to modify the file system. We described a similar decomposition in Chapter 5, Analysis,
when we identified entity, boundary, and control objects. This decomposition is also motivated by
the same considerations about change.
 MVC is well suited for interactive systems, especially when multiple views of the same model are
needed. MVC can be used for maintaining consistency across distributed data; however it
introduces the same performance bottleneck as for other repository styles.
9. Write short notes on adapter, singleton, factory, bridges and observer patterns.
(APRIL/MAY 2011) (May-June’13) (May-June’12) (May-June’11)(Nov-Dec’12) (Nov-
Dec’11) (Nov-Dec’13)
DESIGN PATTERN
 A pattern is a named description of a problem and solution that can applied to new context,
ideally a pattern advises us on how to apply its solution in varying circumstances and
considers the forces and trade-offs.
 Many patterns given a specific category of problem. Guide the assignment of responsibility
to objects.

lOMoARcPSD|40484224
Adapter (GoF) (Nov/Dec-20)
Name: Adapter
Problem: How to resolve incompatible interfaces, or provide a stable interface to

similar components with different interfaces?
Solution: Convert the original interface of a component into another interface, through
(advice) an intermediate adapter objects.
 To review: The NextGen POS system needs to support several kinds of external third-party services,
including tax calculators, credit authorization services, inventory systems, and accounting systems,
among others. Each has a different API, which can't be changed.
 A solution is to add a level of indirection with objects that adapt the varying external interfaces to a
consistent interface used within the application refer figure 3.8.
Figure 3.8 - The Adapter pattern.

lOMoARcPSD|40484224
As illustrated in figure 3.9, a particular adapter instance will be instantiated for the chosen external
service, such as SAP for accounting, and will adapt the postSale request to the external interface,
such as a SOAP XML interface over HTTPS for an intranet Web service offered by SAP.
Figure 3.9 - Using an Adapter.

Guideline: Include Pattern in Type Name
Notice that the type names include the pattern name "Adapter." This is a relatively common style
and has the advantage of easily communicating to others reading the code or diagrams what design
patterns are being used.
Related Patterns
A resource adapter that hides an external system may also be considered a Facade object, as it wraps
access to the subsystem or system with a single object.
Singleton (GoF)
Name: Singleton
Problem: Exactly one instance of a class is allowed it is a "singleton." Objects

need a global and single point of access.
Solution: Define a static method of the class that returns the singleton.
 The Services Factory raises another new problem in the design: Who creates the factory itself, and
how is it accessed?
 First, observe that only one instance of the factory is needed within the process. Second, quick
reflection suggests that the methods of this factory may need to be called from various places in the
code, as different places need access to the adapters for calling on the external services.

lOMoARcPSD|40484224
 Thus, there is a visibility problem: How to get visibility to this single Services Factory instance?
 One solution is passing the Services Factory instance around as a parameter to wherever a visibility
need is discovered for it, or to initialize the objects that need visibility to it, with a permanent
reference. This is possible but inconvenient; an alternative is the Singleton pattern.
 Occasionally, it is desirable to support global visibility or a single access point to a single instance of
a class rather than some other form of visibility. This is true for the ServicesFactory instance.
Figure3.10 - The Singleton pattern in the Services Factory class

Applying UML:
 Notice how a singleton is illustrated a figure 3.10, with a '1' in the top right corner of the name
compartment.
 Thus, the key idea is that class X defines a static method getInstance that itself provides a single
instance of X.
 Since visibility to public classes is global in scope, at any point in the code, in any method of any
class, one can write
 SingletonClass.getInstance():
In order to obtain visibility to the singleton instance, and then send it a message, such as
SingletonClass.getInstance().doFoo().

lOMoARcPSD|40484224
Implementation and Design Issues

A Singleton getInstance method is often frequently called in multi-threaded applications, the
creation step of the lazy initialization logic is a critical section requiring thread concurrency control.
Thus, assuming the instance is lazy initialized, it is common to wrap the method with concurrency
control.
The first approach of lazy initialization is usually preferred for at least these reasons:
 Creation work (and perhaps holding on to "expensive" resources) is avoided, if the instance is never
actually accessed.
 The getInstance lazy initialization sometimes contains complex and conditional creation logic.
Figure 3.11- Implicit getInstance Singleton pattern message in the UML because of the '1' mark.
 Another common Singleton implementation question is: Why not make all the service
methods static methods of the class itself, instead of using an instance object with instance-
side methods? For example, what if we add a static method called getAccountingAdapter to
ServicesFactory (refer figure 3.11). But, an instance and instance-side methods are usually
preferred for these reasons:
 Instance-side methods permit subclassing and refinement of the singleton class into
subclasses; static methods are not polymorphic (virtual) and don't permit overriding in
subclasses in most languages (Smalltalk excluded).
 Most object-oriented remote communication mechanisms (for example, Java's RMI) only
support remote-enabling of instance methods, not static methods. A singleton instance could
be remote-enabled, although that is admittedly rarely done.
 A class is not always a singleton in all application contexts. In application X, it may be a
singleton, but it may be a "multi-ton" in application Y.
Related Patterns
The Singleton pattern is often used for Factory objects and Facade objects.

lOMoARcPSD|40484224
Illustrate and provide an interface for creating families of related or dependent objects without
specifying their concrete classes using factory method. (NOV/DEC 2021)
Factory (GoF)
Name: Factory
Problem: Who should be responsible for creating objects when there are special
considerations, such as complex creation logic, a desire to separate the creation
responsibilities for better cohesion, and so forth?
Solution: Create a Pure Fabrication object called a Factory that handles the creation.
 This is also called Simple Factory or Concrete Factory. This pattern is not a GoF design pattern,
but extremely widespread. It is also a simplification of the GoF Abstract Factory pattern and often
described as a variation of Abstract Factory, although that's not strictly accurate.
 The adapter raises a new problem in the design: In the prior Adapter pattern solution for external
services with varying interfaces, who creates the adapters? And how to determine which class of
adapter to create, such as TaxMaster-Adapter or GoodAsGoldTaxProAdapter?
 If some domain object creates them, the responsibilities of the domain object are going beyond pure
application logic and into other concerns related to connectivity with external software components.
 This point underscores another fundamental design principle: Design to maintain a separation of
concerns. That is, modularize or separate distinct concerns into different areas, so that each has a
cohesive purpose. Fundamentally, it is an application of the GRASP High Cohesion principle.
 Therefore, choosing a domain object (such as a Register) to create the adapters does not support the
goal of a separation of concerns, and lowers its cohesion.
 A common alternative in this case is to apply the Factory pattern, in which a Pure Fabrication
"factory" object is defined to create objects.
Factory objects have several advantages:
 Separate the responsibility of complex creation into cohesive helper objects.

lOMoARcPSD|40484224
 Allow introduction of performance-enhancing memory management strategies, such as object

caching or recycling.
A Factory solution is illustrated in figure 3.12.
Figure 3.12 - The Factory pattern

 Note that in the ServicesFactory, the logic to decide which class to create is resolved by reading in
the class name from an external source and then dynamically loading the class.
 This is an example of a partial data-driven design. This design achieves Protected Variations with
respect to changes in the implementation class of the adapter.
 Without changing the source code in this factory class, we can create instances of new adapter
classes by changing the property value and ensuring that the new class is visible in the Java class
path for loading.
Related Patterns
Factories are often accessed with the Singleton pattern
Strategy (GoF) (behavioral pattern) (NOV/DEC 2015)
 The next design problem to be resolved is to provide more complex pricing logic, such as a store-
wide discount for the day, senior citizen discounts, and so forth.

lOMoARcPSD|40484224
 The pricing strategy (which may also be called a rule, policy, or algorithm) for a sale can vary.
During one period it may be 10% off all sales, later it may be $10 off if the sale total is greater than
$200, and myriad other variations.
 How do we design for these varying pricing algorithms?
 Since the behavior of pricing varies by the strategy (or algorithm), we create multiple
SalePricingStrategy classes, each with a polymorphic getTotal method (see Figure 3.13).
 Each getTotal method takes the Sale object as a parameter, so that the pricing strategy object can
find the pre-discount price from the Sale, and then apply the discounting rule.
 The implementation of each getTotal method will be different: PercentDiscountPricingStrategy will
discount by a percentage, and so on.
Figure 3.13 - Pricing strategy Classes

lOMoARcPSD|40484224
 A strategy object is attached to a context object—the object to which it applies the algorithm. In this
example, the context object is a Sale. When a getTotal message is sent to a Sale, it delegates some of
the work to its strategy object, as illustrated in Figure 3.14.
 It is not required that the message to the context object and the strategy object have the same name,
as in this example (for example, getTotal and getTotal), but it is common.
 However, it is common—indeed, usually required—that the context object pass a reference to itself
(this) on to the strategy object, so that the strategy has parameter visibility to the context object, for
further collaboration.
Figure 3.14 - Strategy in Collaboration

Observe that the context object (Sale) needs attribute visibility to its strategy. This is reflected in the
BCD in Figure 3.15.
Creating a Strategy with a Factory
 There are different pricing algorithms or strategies, and they change over time.
 Who should create the strategy? A straightforward approach is to apply the Factory pattern again: a
PricingStrategyFactory can be responsible for creating all strategies (all the pluggable or changing
algorithms or policies) needed by the application.
 As with the SeruicesFactory, it can read the name of the implementation class of the pricing strategy
from a system property (or some external data source), and then make an instance of it.
 With this partial data-driven design (or reflective design) one can dynamically change at any time—
while the NextGen POS application is running—the pricing policy, by specifying a different class of
Strategy to create.

lOMoARcPSD|40484224
 Observe that a new factory was used for the strategies; that is, different than the SeruicesFactory.
This supports the goal of High Cohesion—each factory is cohesively focused on creating a related
family of objects.
Figure 3.15 - Context object needs attribute visibility to its Strategy

 UML notation—Observe that in Figure 3.15 the reference via a directed association is to the
interface ISalePricingStrategy, not to a concrete class.
 This indicates that the reference attribute in the Sale will be declared in terms of the interface, not a
class, so that any implementation of the interface can be bound to the attribute.
 Note that because of the frequently changing pricing policy (it could be every hour), it is not
desirable to cache the created strategy instance in a field of the PricingStrategyFactory, but rather to
re-create one each time, by reading the external property for its class name, and then instantiating the
strategy.
 And as with most factories, the PricingStrategyFactory will be a singleton (one instance) and
accessed via the Singleton pattern (see Figure 3.16)

lOMoARcPSD|40484224
Figure 3.16 - Creating Strategy and Factory for Strategies

lOMoARcPSD|40484224
Bridges
 The bridge pattern is a design pattern used in software engineering which is meant to "decouple an
abstraction from its implementation so that the two can vary independently".
 The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into
different classes.
 When a class varies often, the features of object-oriented programming become very useful because
changes to a program's code can be made easily with minimal prior knowledge about the program.
The bridge pattern is useful when both the class and what it does vary often.
 The class itself can be thought of as the implementation and what the class can do as the abstraction.
The bridge pattern can also be thought of as two layers of abstraction.
 When there is only one fixed implementation, this pattern is known as the Pimple idiom in the C++
world.
 The bridge pattern is often confused with the adapter pattern. In fact, the bridge pattern is often
implemented using the class adapter pattern, e.g. in the Java code below.
 Variant: The implementation can be decoupled even more by deferring the presence of the
implementation to the point where the abstraction is utilized.
Figure 3.17 - Bridge Pattern

Abstraction (abstract class)

lOMoARcPSD|40484224
 Defines the abstract interface

 Maintains the Implementor reference.
RefinedAbstraction (normal class)

 Extends the interface defined by Abstraction
Implementor (interface)
 Defines the interface for implementation classes
ConcreteImplementor (normal class)

 Implements the Implementor interface
Would I Use This Pattern?

 The Bridge pattern (see figure 3.17) should be used when both the class as well as what it does vary
often.
 The bridge pattern can also be thought of as two layers of abstraction. When the abstractions and
implementations should not be bound at compile time, and should be independently extensible the
pattern should be used.
 In particular this pattern is useful in graphic toolkits that need to run on multiple platforms. In
AWT, where a component has a component peer which does the OS specific operations. Also, the
Collections framework has examples of the bridge interface: ArrayList and LinkedList are
implement List. And List provides common methods to add, remove or check size.
Observer/Publish-Subscribe/Delegation Event Model (GoF) (behavioral pattern) (NOV/DEC
2015)
Name: Observer (Publish-Subscribe)
Problem: Different kinds of subscriber objects are interested in the state changes or
events of a publisher object, and want to react in their own unique way when
the publisher generates an event. Moreover, the publisher wants to maintain
low coupling to the subscribers. What to do?
Solution: Define a "subscriber" or "listener" interface. Subscribers implement this

lOMoARcPSD|40484224
Name: Observer (Publish-Subscribe)
interface. The publisher can dynamically register subscribers who are

interested in an event and notify them when an event occurs.
Another requirement for the iteration is adding the ability for a GUI window to refresh its display of
the sale total when the total changes is shown in figure 3.18. The idea is to solve the problem for this
one case, and then in later iterations, extend the solution to refreshing the GUI display for other
changing data as well.
Figure 3.18 - Updating the interface when the sale total changes.
 When the Sale changes its total, the Sale object sends a message to a window, asking it to refresh its
display.
 To review, the Model-View Separation principle discourages such solutions. It states that "model"
objects (non-UI objects such as a Sale) should not know about view or presentation objects such as a
window. It promotes Low Coupling from other layers to the presentation (UI) layer of objects.
 A consequence of supporting this low coupling is that it allows the replacement of the view or
presentation layer by a new one, or of particular windows by new windows, without impacting the
non-UI objects.
 If model objects do not know about Java Swing objects (for example), then it is possible to unplug a
Swing interface, or unplug a particular window, and plug in something else.
 Thus, Model-View Separation supports Protected Variations with respect to a changing user
interface.

lOMoARcPSD|40484224
 To solve this design problem, the Observer pattern (see figure 3.19) can be used.
Figure 3.19 The Observer pattern.

The major ideas and steps in this example:
1. An interface is defined; in this case, PropertyListener with the operation
onPropertyEvent.
2. Define the window to implement the interface.
o SaleFrame1 will implement the method onPropertyEvent.
3. When the SaleFrame1 window is initialized, pass it the Sale instance from which it
is displaying the total.

lOMoARcPSD|40484224
4. The SaleFrame1 window registers or subscribes to the Sale instance for notification
of "property events," via the addPropertyListener message. That is, when a property (such as total)
changes, the window wants to be notified.
5. Note that the Sale does not know about SaleFrame1 objects; rather, it only knows
about objects that implement the PropertyListener interface. This lowers the coupling of the Sale to
the windowthe coupling is only to an interface, not to a GUI class.
6. The Sale instance is thus a publisher of "property events." When the total changes, it
iterates across all subscribing PropertyListeners, notifying each.
The SaleFrame1 object is the observer/subscriber/listener. In Figure 3.20, it subscribes to interest in

property events of the Sale, which is a publisher of property events. The Sale adds the object to its
list of PropertyListener subscribers. Note that the Sale does not know about the SaleFrame1 as a
SaleFrame1 object, but only as a PropertyListener object; this lowers the coupling from the model up
to the view layer.
Figure 3.20 - The observer SaleFrame1 subscribes to the publisher Sale.

When the Sale total changes, it iterates across all its registered subscribers, and "publishes an event"
by sending the on PropertyEvent message to each (see figure 3.21).

lOMoARcPSD|40484224
Figure 3.21- The Sale publishes a property event to all its subscribers.
Applying UML: Note the approach to handing polymorphic messages in an interaction diagram in
the figure 3.22, The onPropertyEvent message is polymorphic; the specific cases of polymorphic
implementation will be shown in other diagrams.
Figure 3.22 - The subscriber SaleFrame1 receives notification of a published event.

 SaleFrame1, which implements the PropertyListener interface, thus implements an onPropertyEvent
method. When the SaleFrame1 receives the message, it sends a message to its JTextField GUI
widget object to refresh with the new sale total.
 In this pattern, there is still some coupling from the model object (the Sale) to the view object (the
SaleFrame1). But it is a loose coupling to an interface independent of the presentation layer the
PropertyListener interface. And the design does not require any subscriber objects to actually be
registered with the publisher (no objects have to be listening). That is, the list of registered
PropertyListeners in the Sale can be empty.
 In summary, coupling to a generic interface of objects that do not need to be present, and which can
be dynamically added (or removed), supports low coupling. Therefore, Protected Variations with
respect to a changing user interface has been achieved through the use of an interface and
polymorphism.
Why Is It Called Observer, Publish-Subscribe, or Delegation Event Model?

 Originally, this idiom was called publish-subscribe, and it is still widely known by that name. One
object "publishes events," such as the Sale publishing the "property event" when the total changes.

lOMoARcPSD|40484224
 No object may be interested in this event, in which case, the Sale has no registered subscribers. But
objects that are interested, "subscribe" or register to interest in an event by asking the publishing to
notify them. This was done with the Sale.addPropertyListener message. When the event happens, the
registered subscribers are notified by a message.
 It has been called Observer because the listener or subscriber is observing the event; that term was
popularized in Smalltalk in the early 1980s.
 It has also been called the Delegation Event Model (in Java) because the publisher delegates
handling of events to "listeners" is shown in figure 3.23.
Figure 3.23-Who is the observer, listener, subscriber, and publisher

Observer Is Not Only for Connecting UIs and Model Objects
 The previous example illustrated connecting a non-UI object to a UI object with Observer. However,
other uses are common.
 The most prevalent use of this pattern is for GUI widget event handling, in both Java technologies
(AWT and Swing) and in Microsoft's .NET. Each widget is a publisher of GUI-related events, and
other objects can subscribe to interest in these.

lOMoARcPSD|40484224
 For example, a Swing JButton publishes an "action event" when it is pressed. Another object will
register with the button so that when it is pressed, the object is sent a message and can take some
action.
Related Patterns
Observer is based on Polymorphism, and provides Protected Variations in terms of protecting the
publisher from knowing the specific class of object, and number of objects, that it communicates
with when the publisher generates an event.
9. Explain in detail about Command design patterns in software design.

 In interactive systems and in transaction systems, it is often desirable to execute, undo, or store
user requests without knowing the content of the request. For example, consider the case of
matches in the ARENA tournament management system. We want to record individual moves
in matches so that these moves can be replayed by a spectator at a later date.
 However, we also want ARENA to support a broad spectrum of games, so we do not want the
classes responsible for recording and replaying moves to depend on any specific game. We can
apply the Command design pattern (Appendix A.4, [Gamma et al., 1994]) to this effect. The key
to decoupling game moves from their handling is to represent game moves as command objects
that inherit from an abstract class called Move in Figure 3.24.
 The Move class declares operations for executing, undoing, and storing commands, whereas
ConcreteCommands classes (i.e., TicTacToeMove and ChessMove in ARENA) implement
specific commands. The classes responsible for recording and replaying games only access the
GameMove abstract class interface, thus making the system extensible to new Games.

lOMoARcPSD|40484224
Figure 3.24 - Applying the Command design pattern to Matches in ARENA (UML class
diagram).
Inheritance and delegation in the Command pattern
 The Command design pattern uses specification inheritance between the Command
class and ConcreteCommands, enabling new commands to be added independently
from the Invoker. Delegation is used between ConcreteCommands and Receivers, and
between Invoker and Command, enabling ConcreteCommands to be dynamically
created, executed, and stored.
 The Command pattern is often used in a Model/View/Controller software architecture,
where Receivers are model objects, Invoker and Commands are controller objects, and
Clients creating Commands are view objects.
Applying the Command Design Pattern
 Although Spectators can watch Matches as they occur, we anticipate that many Matches will
be viewed asynchronously, after the fact.
 We apply the Command design pattern and represent each move as a Command object. The
abstract Move object (corresponding to the Command object in the design pattern) provides
the interface to the League and Tournament objects to manipulate Moves independently
from the concrete Games and Matches. The concrete Moves are created by and stored in a
queue in the concrete Match object (Figure 3.25).
 To deal with concurrent Spectators replaying the same Match, we need to refine this
solution further. For each request to replay an archived Match, ARENA creates a new
ReplayedMatch that includes its own GameBoard to hold the current state of the replayed
Match and feeds it the Move objects of the archived Match, one at the time. This enables the
same Match to be replayed by many different Spectators independently.

lOMoARcPSD|40484224
Figure 3.25 - Applying the Command design pattern to Matches and ReplayedMatches
in ARENA (UML class diagram).
10. Explain about Strategy design pattern in detail.

Encapsulating Context with the Strategy Pattern:
 Consider a mobile application running on a wearable computer that uses different networks
protocols depending on the location of the user: assume, for example, a car mechanic using
the wearable computer to access repair manuals and maintenance records for the vehicle under
repair. The wearable computer should operate in the shop with access to a local wireless
network as well as on the roadside using a third-generation mobile phone network, such as
UMTS.
 When updating or configuring the mobile application, a system administrator should be able
to use the wearable computer with access to a wired network such as Ethernet. This means
that the mobile application needs to deal with different types of networks as it switches
between networks dynamically, based on factors such as location and network costs. Assume
that during the system design of this application, we identify the dynamic switching between
wired and wireless networks as a critical design goal. Furthermore we want to be able to deal
with future network protocols without having to recompile the application.
 To achieve both of these goals, we apply the Strategy design pattern (Appendix A.9, [Gamma
et al., 1994]). The system model and implementation, respectively, are shown in Figures 3.26
and 3.27. The Strategy class is realized by NetworkInterface, which provides the common
interface to all networks; the Context class is realized by a NetworkConnection object, which
represents a point-to-point connection between the wearable and a remote host. The Client is
the mobile application.
 The Policy is the LocationManager, which monitors the current location of the wearable and
the availability of networks, and configures the NetworkConnection objects with the
appropriate NetworkInterfaces. When the LocationManager object invokes the
setNetworkInterface() method, the NetworkConnection object shuts down the current
NetworkInterface and initializes the new NetworkInterface transparently from the rest of the
application.

lOMoARcPSD|40484224
Figure 3.26 - Applying the Strategy pattern for encapsulating multiple implementations
of a NetworkInterface (UML class diagram). The LocationManager implementing a
specific policy configures NetworkConnection with a concrete NetworkInterface (i.e., the
mechanism) based on the current location. The Application uses the NetworkConnection
independently of concrete NetworkInterfaces.
Inheritance and delegation in the Strategy pattern

The class diagrams for the Bridge and the Strategy patterns (see Figures 3.17 and 3.26) are almost
identical. The key difference is in the creator of the concrete implementation classes: In the Bridge
pattern, the class Abstraction creates and initializes the ConcreteImplementations. In the Strategy
pattern, however, the Context is not aware of the ConcreteStrategies. Instead, a client creates the
ConcreteStrategy objects and configures the Context. Moreover, ConcreteImplementations in the
Bridge pattern are usually created at initialization time, while ConcreteStrategies in the Strategy
pattern are usually created and substituted several times during run time.
Strategy: Encapsulating Algorithms
Name: Strategy Design Pattern
Problem description: Decouple a policy-deciding class from a set of mechanisms so that different
mechanisms can be changed transparently from a client.
Solution: A Client accesses services provided by a Context. The Context services are realized using
one of several mechanisms, as decided by a Policy object. The abstract Strategy class describes the
interface that is common to all mechanisms that Context can use. The Policy class creates a
Concrete– Strategy object and configures the Context to use it.

lOMoARcPSD|40484224
Figure 3.27 – Strategy Design Pattern

Consequences
• ConcreteStrategies can be substituted transparently from Context.
• Policy decides which Strategy is best, given the current circumstances (e.g., speed vs. space trade-
off).
• New algorithms can be added without modifying Context or Client.
Example
• Network switching in mobile applications : A mobile application needs to deal with a variety of
network access protocols (phone, wireless, LAN), depending on the context of the user (location,
communication costs, etc.). To decouple the policy from selecting a network from the network
interface, we encapsulate the network access protocol implementations with a Strategy pattern.
11. Explain in detail about Proxy Design Pattern.

 An object that acts on the behalf of another one is called a “proxy.” We therefore create two
new classes, SegmentProxy and TripProxy, and make them part of the RoutingSubsystem.
These proxies are examples of the Proxy design pattern.
Delaying expensive computations
 Often, specific objects are expensive to create. However, their creation can often be delayed
until their actual content is needed. For example, consider an object representing an image
stored as a file (e.g., an ARENA AdvertisementBanner).
 Loading all the pixels that constitute the image from the file is expensive. However, the
image data need not be loaded until the image is displayed. We can realize such an
optimization using a Proxy design pattern [Gamma et al., 1994].

lOMoARcPSD|40484224
 An ImageProxy object takes the place of the Image and provides the same interface as the
Image object (Figure 3.28). Simple operations such as width() and height() are handled by
ImageProxy.
 When Image needs to be drawn, however, ImageProxy loads the data from disk and creates
a RealImage object. If the client does not invokes the paint() operation, the RealImage
object is not created, thus saving substantial computation time.
 The calling classes only access the ImageProxy and the RealImage through the Image
interface.
Figure 3.28 - Delaying expensive computations to transform the object design model using a
Proxy design pattern (UML class diagram).
Proxy: Encapsulating Expensive Objects

Name: Proxy Design Pattern
Problem description: Improve the performance or the security of a system by delaying expensive
computations, using memory only when needed, or checking access before loading an object into
memory.
Solution: The ProxyObject class acts on behalf of a RealObject class. Both classes implement the
same interface. The ProxyObject stores a subset of the attributes of the RealObject. The

lOMoARcPSD|40484224
ProxyObject handles certain requests completely (e.g., determining the size of an image), whereas
others are delegated to the RealObject. After delegation, the RealObject is created and loaded in
memory.
Figure 3.29 – Proxy Design pattern

Consequences
• Adds a level of indirection between Client and RealObject.
• The Client is shielded from any optimizations for creating RealObjects.
Examples
• Protection proxy (Figure 3.29): An Access association class contains a set of operations that a
Broker can use to access a Portfolio.
 Every operation in the PortfolioProxy first checks with isAccessible() if the invoking Broker
has legitimate access. Once access has been granted, PortfolioProxy delegates the operation
to the actual Portfolio object. If access is denied, the actual Portfolio object is not loaded
into memory.
 Storage proxy : An ImageProxy object acts on behalf of an Image stored on disk. The
ImageProxy contains the same information as the Image (e.g., width, height, position,
resolution) except for the Image contents. The ImageProxy services all content-independent
requests. Only when the Image contents must be accessed (e.g., when the Image is drawn on
the screen) does the ImageProxy create the RealImage object and load its contents from
disk.
12. Explain about Façade Design pattern.

Encapsulating subsystems with the Facade design pattern:

lOMoARcPSD|40484224
 Subsystem decomposition reduces the complexity of the solution domain by minimizing

coupling among subsystems. The Facade design pattern (see Appendix A.6 and [Gamma et
al., 1994]) allows us to further reduce dependencies between classes by encapsulating a
subsystem with a simple, unified interface.
 For example, in Figure 3.30, the Compiler class is a façade hiding the classes CodeGenerator,
Optimizer, ParseNode, Parser, and Lexer. The façade provides access only to the public
services offered by the subsystem and hides all other details, effectively reducing coupling
between subsystems.
Figure 3.30 - An example of the Facade design pattern (UML class diagram)
 Subsystems identified during the initial subsystem decomposition often result from
grouping several functionally related classes. These subsystems are good candidates for
the Facade design pattern and should be encapsulated under one class.
Façade: Encapsulating Subsystems
Name: Facade Design Pattern
Problem description: Reduce coupling between a set of related classes and the rest of the
system.
Solution: A single Facade class implements a high-level interface for a subsystem by
invoking the methods of lower-level classes. A Facade is opaque in the sense that a caller

lOMoARcPSD|40484224
does not access the lower-level classes directly. The use of Facade patterns recursively
yields a layered system.
Figure 3.31 – Façade design pattern

Consequences
• Shields a client from the low-level classes of a subsystem.
• Simplifies the use of a subsystem by providing higher-level methods.
Example
• Subsystem encapsulation (Figure 3-30): A Compiler is composed of Lexer, Parser, ParseTree, a
CodeGenerator, and an Optimizer. When compiling a string into executable code, however, a caller
deals only with the Compiler class, which invokes the appropriate methods on the contained
classes.
14. Write short notes on Architectural styles. What is software architecture? Describe in
detail about different types of software architectures with illustrations. (or) What is
software architecture? Explain the different architectural styles with examples. (or) What
is software architecture? Outline the architectural styles with an example. (or) what are
the different types of architectural styles exist for software and explain any software
architecture in detail . (Apr/May 2021)

lOMoARcPSD|40484224
 Software architecture: At the most simplistic level, you think about the overall shape of
the physical structure. But in reality, architecture is much more. It is the manner in which
the various components of the building are integrated to form a cohesive whole. It is the
way in which the building fits into its environment and meshes with other buildings in its
vicinity.
 The software that is built for computer-based systems exhibits one of many architectural
styles. Each style describes a system category that encompasses
(1) a set of components (e.g., a database, computational modules) that perform a
function required by a system;
(2) a set of connectors that enable “communication, coordination and cooperation”
among components;
(3) constraints that define how components can be integrated to form the system;
and
(4) semantic models that enable a designer to understand the overall properties of a
system by analyzing the known properties of its constituent parts.
 An architectural style is a transformation that is imposed on the design of an entire system.
The intent is to establish a structure for all components of the system. In the case where an
existing architecture is to be reengineered, the imposition of an architectural style will result
in fundamental changes to the structure of the software including a reassignment of the
functionality of components.
 An architectural pattern, like an architectural style, imposes a transformation on the design
of architecture. However, a pattern differs from a style in a number of fundamental ways:
(1) The scope of a pattern is less broad, focusing on one aspect of the architecture
rather than the architecture in its entirety;
(2) A pattern imposes a rule on the architecture, describing how the software will
handle some aspect of its functionality at the infrastructure level (e.g., concurrency);
(3) Architectural patterns tend to address specific behavioral issues within the
context of the architecture (e.g., how real-time applications handle synchronization
or interrupts).
 Patterns can be used in conjunction with an architectural style to shape the overall structure
of a system.

lOMoARcPSD|40484224
A Brief Taxonomy of Architectural Styles

 Although millions of computer-based systems have been created over the past 60 years, the
vast majority can be categorized into one of a relatively small number of architectural styles:
Data-centered architectures.
 A data store (e.g., a file or database) resides at the center of this architecture and is accessed
frequently by other components that update, add, delete, or otherwise modify data within the
store.
 Figure 3.32 illustrates a typical data-centered style. Client software accesses a central
repository. In some cases the data repository is passive. That is, client software accesses the
data independent of any changes to the data or the actions of other client software. A
variation on this approach transforms the repository into a “blackboard” that sends
notifications to client software when data of interest to the client changes.
 Data-centered architectures promote integrability. That is, existing components can be
changed and new client components added to the architecture without concern about other
clients (because the client components operate independently).
 In addition, data can be passed among clients using the blackboard mechanism (i.e., the
blackboard component serves to coordinate the transfer of information between clients).
Client components independently execute Processes.

lOMoARcPSD|40484224
Figure 3.32 – Data centered architecture

Data-flow architectures.
 This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data. A pipe-and-filter pattern
(Figure 3.33) has a set of components, called filters, connected by pipes that transmit data
from one component to the next. Each filter works independently of those components
upstream and downstream, is designed to expect data input of a certain form, and produces
data output (to the next filter) of a specified form. However, the filter does not require
knowledge of the working of its neighboring filters.
 If the data flow degenerates into a single line of transforms, it is termed batch sequential.
This structure accepts a batch of data and then applies a series of sequential components
(filters) to transform it.

lOMoARcPSD|40484224
Figure 3.33 – Data-flow architecture

Call and return architectures.
This architectural style enables you to achieve a program structure that is relatively easy to modify
and scale. A number of sub styles [Bas03] exist within this category:
 Main program/subprogram architectures. This classic program structure decomposes
function into a control hierarchy where a “main” program invokes a number of program
components that in turn may invoke still other components. Figure 3.34 illustrates
architecture of this type.

lOMoARcPSD|40484224
Figure 3.34 – Main Program/Subprogram architecture
 Remote procedures call architectures. The components of main program/subprogram

architecture are distributed across multiple computers on a network.
 Object-oriented architectures
 The components of a system encapsulate data and the operations that must be applied to
manipulate the data.
 Communication and coordination between components are accomplished via message
passing.
 Layered architectures
 The basic structure of a layered architecture is illustrated in Figure 3.35. A number of
different layers are defined, each accomplishing operations that progressively become closer
to the machine instruction set.
 At the outer layer, components service user interface operations.

lOMoARcPSD|40484224
 At the inner layer, components perform operating system interfacing.

 Intermediate layers provide utility services and application software functions.
Figure 3.35 – Layered Architecture

Architectural Patterns
 As the requirements model is developed, one will notice that the software must address a
number of broad problems that span the entire application. For example, the requirements
model for virtually every e-commerce application is faced with the following problem: How
do we offer a broad array of goods to a broad array of customers and allow those
customers to purchase our goods online?
 The requirements model also defines a context in which this question must be answered. For
example, an e-commerce business that sells golf equipment to consumers will operate in a
different context than an e-commerce business that sells high-priced industrial equipment to
medium and large corporations. In addition, a set of limitations and constraints may affect
the way in which you address the problem to be solved.
 Architectural patterns address an application-specific problem within a specific context and
under a set of limitations and constraints. The pattern proposes an architectural solution
that can serve as the basis for architectural design.
Organization and Refinement
The following questions provide insight into an architectural style:
Control

lOMoARcPSD|40484224
 How is control managed within the architecture?

 Does a distinct control hierarchy exist, and if so, what is the role of components within this
control hierarchy?
 How do components transfer control within the system?
 How is control shared among components?
 What is the control topology (i.e., the geometric form that the control takes)?
 Is control synchronized or do components operate synchronously?
Data
 How are data communicated between components?
 Is the flow of data continuous, or are data objects passed to the system sporadically?
 What is the mode of data transfer (i.e., are data passed from one component to another or are
data available globally to be shared among system components)?
These questions provide the designer with an early assessment of design quality and lay the
foundation for more detailed analysis of the architecture.
15. Give notes on User Interface Design. (Or) Describe the golden rules for interface design.
(Or) Discuss about User Interface Design of Software with an example and neat sketch. (or)
Discuss about User Interface Design of Software with an example and neat sketch.
 First, a set of golden rules were identified. These applied to all human interaction with
technology products.
 Second, a set of interaction mechanisms were defined to enable software designers to build
systems that properly implemented the golden rules.
 These interaction mechanisms, collectively called the graphical user interface (GUI), have
eliminated some of the most egregious problems associated with human interfaces.
The Golden rules
Theo Mandel [Man97] coins three golden rules:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.

lOMoARcPSD|40484224
These golden rules actually form the basis for a set of user interface design principles that guide this
important aspect of software design.
Place the User in Control
Mandel defines a number of design principles that allow the user to maintain control:
 Define interaction modes in a way that does not force a user into unnecessary or
undesired actions.
An interaction mode is the current state of the interface. For example, if spell check is selected
in a word-processor menu, the software moves to a spell-checking mode. There is no reason to
force the user to remain in spell-checking mode if the user desires to make a small text edit
along the way. The user should be able to enter and exit the mode with little or no effort.
 Provide for flexible interaction.
Because different users have different interaction preferences, choices should be provided. For
example, software might allow a user to interact via keyboard commands, mouse movement, a
digitizer pen, a multitouch screen, or voice recognition commands. But every action is not
amenable to every interaction mechanism. Consider, for example, the difficulty of using
keyboard command (or voice input) to draw a complex shape.
 Allow user interaction to be interruptible and undoable.
Even when involved in a sequence of actions, the user should be able to interrupt the sequence
to do something else (without losing the work that had been done). The user should also be
able to “undo” any action.
 Streamline interaction as skill levels advance and allow the interaction to be customized.
Users often find that they perform the same sequence of interactions repeatedly. It is
worthwhile to design a “macro” mechanism that enables an advanced user to customize the
interface to facilitate interaction.
 Hide technical internals from the casual user.
The user interface should move the user into the virtual world of the application. The user
should not be aware of the operating system, file management functions, or other arcane
computing technology. In essence, the interface should never require that the user interact at a
level that is “inside” the machine (e.g., a user should never be required to type operating
system commands from within application software).
 Design for direct interaction with objects that appear on the screen.

lOMoARcPSD|40484224
The user feels a sense of control when able to manipulate the objects that are
necessary to perform a task in a manner similar to what would occur if the object
were a physical thing. For example, an application interface that allows a user to
“stretch” an object (scale it in size) is an implementation of direct manipulation.
Reduce the User’s Memory Load
Mandel [Man97] defines design principles that enable an interface to reduce the user’s memory
load:
 Reduce demand on short-term memory.
 When users are involved in complex tasks, the demand on short-term memory can be
significant.
 The interface should be designed to reduce the requirement to remember past actions,
inputs, and results. This can be accomplished by providing visual cues that enable a user to
recognize past actions, rather than having to recall them.
 Establish meaningful defaults.
 The initial set of defaults should make sense for the average user, but a user should be able
to specify individual preferences.
 However, a “reset” option should be available, enabling the redefinition of original default
values.
 Define shortcuts that are intuitive.
 When mnemonics are used to accomplish a system function (e.g., alt-P to invoke the
print function), the mnemonic should be tied to the action in a way that is easy to
remember (e.g., first letter of the task to be invoked).
 The visual layout of the interface should be based on a real-world metaphor.
 For example, a bill payment system should use a checkbook and check register
metaphor to guide the user through the bill paying process. This enables the user to rely
on well-understood visual cues, rather than memorizing an arcane interaction sequence.
 Disclose information in a progressive fashion.
 The interface should be organized hierarchically. That is, information about a task, an
object, or some behavior should be presented first at a high level of abstraction. More
detail should be presented after the user indicates interest with a mouse pick.

lOMoARcPSD|40484224
 An example, common to many word-processing applications, is the underlining

function. The function itself is one of a number of functions under a text style menu.
However, every underlining capability is not listed. The user must pick underlining;
then all underlining options (e.g., single underline, double underline, dashed underline)
are presented.
Make the Interface Consistent
Mandel defines a set of design principles that help make the interface consistent:
 Allow the user to put the current task into a meaningful context. Many interfaces
implement complex layers of interactions with dozens of screen images. It is important to
provide indicators (e.g., window titles, graphical icons, consistent color coding) that enable the
user to know the context of the work at hand. In addition, the user should be able to determine
where he has come from and what alternatives exist for a transition to a new task.
 Maintain consistency across a family of applications.
A set of applications (or products) should all implement the same design rules so that
consistency is maintained for all interaction.
 If past interactive models have created user expectations, do not make changes unless
there is a compelling reason to do so.
Once a particular interactive sequence has become a de facto standard (e.g., the use of alt-S to
save a file), the user expects this in every application he encounters. A change (e.g., using alt-S
to invoke scaling) will cause confusion.

Unit-3 Oose

Uploaded by

Copyright:

Available Formats

Unit-3 Oose

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

Unit-3 Oose

Uploaded by

Copyright:

Available Formats

lOMoARcPSD|40484224

UNIT 3 Final COPY - notes

Object Oriented Software Engineering (Anna University)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

UNIT III SOFTWARE DESIGN

2. What are the four major areas of concern in design?

3. Define - Software design.

4. Mention three characteristics for the evaluation of a good design.

The eight software design principles are:

PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 1

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

(2) is composed of components that exhibit good design characteristics , and

7. Define - Software architecture.

PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 2

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

10. Define fan in and fan out.

11. Explain the terms: Visibility and Connectivity.

12. What are the benefits of horizontal partitioning?

13. What are the two types of structural partitioning? Explain.

14. What is a data structure?

PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 3

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

 It dictates the organization method of access, degree of associativity and processing

15. Explain the qualitative criteria for measuring independence.

16. Explain the following.

18. Mention any four design heuristics.

19. With a neat diagram, describe the design model.

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

20. What is the purpose of a cross reference in the design specification?

21. Why is software architecture important?

PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 5

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

23. What is an architectural style?

24. List any four architectural styles.

25. Define - Transform Mapping.

26. Explain - Transform Flow.

27. List out the design steps in transform mapping.

PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 6

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

28. What happens after the architecture has been created?

32. How do we design interfaces that reduce user's memory load?

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

35. Classify the different forms of user interaction.

PREPARED BY: Mrs.P.R.JAYANTHI AP/CSE, Ms.G.SARASWATHI AP/CSE, Mrs.K.KAVITHA AP/CSE Page 8

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3

38. Name the three areas that provide user guidance.

39. List the design factors in message wording.

Downloaded by VENKAT VIJAY MP ([email protected])

CCS356 OBJECT ORIENTED SOFTWARE ENGINEERING UNIT 3