SOFTWARE ENGINEERING

UNIT – III
BUILDING THE ANALYSIS MODEL
In this chapter:
✓ Requirement analysis
✓ Analysis modeling approaches
✓ Data modeling concepts
✓ Object oriented analysis
✓ Flow oriented modeling
✓ Design engineering
✓ Design concepts
✓ The design model
✓ Modeling component level design
✓ Designing class based components

REQUIREMENT ANALYSIS

Requirements analysis results in the specification of software’s operational

characteristics; indicates software’s interface with other system elements; and
establishes constraints that software must meet.
Requirements analysis allows the software engineer to elaborate on basic
requirements established during earlier requirement engineering tasks and build
models that depict users scenarios, functional activities, problem classes and their
relationships, system and class behavior and the flow of data.
Requirements analysis provides the software designers with a representation of
Information
Functions
Behavior
Which can be translated to
Architectural
Interface
Component level design
The analysis model and requirement specification provide a means for
assessing quality once the software is built
1. Overall Objectives and Philosophy

The analysis model must achieve three primary objectives :

To describe what the customer requires.
To establish a basis for the creation of a software design
To define a set of requirements that can be validated once the
software is built.
The analysis model bridges the gap between a system-level description.
That describes the overall system functionality as it is achieved by applying
software, hardware, data, human, and other system elements and a software design that
describes the software’s application architecture, user interface, and component level
structure.
2. Analysis rules of thumbs
The model focuses on the requirements in the business domain. The level of
abstraction must be high i.e there is no need to give details.
Every element in the model helps in understanding the software requirement
and focus on the information, function and behaviour of the system.
The consideration of infrastructure and nonfunctional model delayed in the
design. For example, the database is required for a system, but the classes, functions
and behavior of the database are not initially required. If these are initially considered
then there is a delay in the designing.
Throughout the system minimum coupling is required. The interconnections
between the modules is known as 'coupling'.
The analysis model gives value to all the people related to model.
The model should be simple as possible. Because simple model always helps
in easy understanding of the requirement.
3. Domain analysis
Domain Analysis is the process that identifies the relevant objects of an
application domain.
The goal of Domain Analysis is Software Reuse.
The higher is the level of the life-cycle object to reuse, the larger are the benefits
coming from its reuse, the harder is the definition of a workable process.
Frameworks are excellent candidates for Domain Analysis: they are at a higher
level than code but average programmers can understand them.

In way the role of a domain analyst is similar to the role of a master toolsmith
in a heavy manufacturing environment.
The job of the toolsmith is to design and build tools that may be used by many
people doing similar but not necessarily the same job.
The role of domain analyst is to discover and define reusable analysis patterns,
analysis classes, and related information that may be used by many people working on
similar but not necessarily the same applications.

ANALYSIS MODELING APPROACHES

Structured Analysis: It is a structural viewpoint that shows the architecture of
the system or data. It involves the data model like the entity-relationship
diagram. It considers data and the processes that transform the data into
separate entities called as data objects. Data objects define the attributes and
relationships. This process tells us how we can manipulate and transform the
data. It also represents the flow of data objects.

Object-Oriented Analysis: It focus on the definition of classes. It provides

object-oriented design methodology such as UML and Unified process
analysis. It performs collaboration of classes to fulfill the user’s requirements.

Importance of Analysis Modeling

Given below are the importance mentioned:
The analysis model is multidimensional.
The design modeling phase completely depends upon the analysis model.
If any deficiency remains in the analysis model, then errors will be found in the
ultimate product to be built.
DATA MODELING CONCEPTS

Analysis modeling often begins with data modeling.

The software engineer or analyst defines all data objects that are processed
within the system, the relationships between the data objects and other information that
is pertinent to the relationships.

Data Objects
Data object is a representation of almost any composite information that must be
understood by software.
By composite information, something that has number of different properties or
attributes.
A data object can be an
external entity( eg : anything that produces or consumes
information),
a thing (eg : a report or display),
an occurrence (eg: telephone call) or
event (eg : alarm),
a role (eg : salesperson)
an organizational unit (eg : accounting department)
a place
a structure.
A data object encapsulates the data only – there is no reference within a data
object to operations that act on the data.

Data Attributes
Attributes define the properties of a data object. The attribute is a quality or
characteristic that defines a person, group, or data objects.
It is actually the properties that define the type of entity. An attribute can have
a single or multiple or range of values as per our needs.
There are three types of attributes:
1. Naming attributes –
To name an instance of a data object, naming attributes are used. User naming
attributes identify user objects such as Login_names and User_Id for some
security purpose.
For example- Make and model are naming attributes in a vehicle data object.
2. Descriptive attributes –
These attributes are used to describe the characteristics or features or the
relationship of the data object. Sometimes also referred to as relationship
attributes.
For example- In a vehicle, the color of a data object is a descriptive attribute
that describes the features of the object.
3. Referential attribute –
These are the attributes that are used to formalize binary and associative
relationships and in making reference to another instance in another table.
For example- The data object is a referential attribute in a vehicle.
Relationship :
The relationship represents the connection or relation between different data
objects and describes association among entities. Relationships are of three types:
one-to-many, many-to-many, and many-to-one.
For example, toy and shopkeeper are two objects that share the following
relationship:
The Shopkeeper order toys.
The shopkeeper sells toys.
The shopkeeper shows toys.
The Shopkeeper stocks toys.
Cardinality and Modality
Cardinality describes the maximum number of data objects that can participate
in a relationship. In databases, cardinality is defined as the uniqueness of data values
that are contained in a column.
High cardinality means the column contains a large percentage of totally unique
values. On the other hand, low cardinality means the column has a lot of "repeats" in
its data range.
Cardinality between the tables can be classified into different types such as
one−to−one, many−to−one or many−to−many.
Modality is absolutely different from cardinality because −
The value of modality is computed as "0", if the relationship is optional or if
there is no need for the relationship to occur.
If there is a necessity of the occurrence of a relationship, then the value of the
modality is computed as "1".

OBJECT ORIENTED ANALYSIS

The intent of Object – Oriented analysis (OOA) is to define all classes that are
relevant to the problem to be solved.
To accomplish this, a number of tasks must occur :
Basic user requirements must be communicated between the
customer and the software engineer.
Classes must be identified
A class hierarchy is defined
Object – to – object relationships should be represented.
Object behavior must be modeled.
Tasks 1 through 5 are reapplied iteratively until the model is
complete.
FLOW ORIENTED MODELING
Data flow-oriented modeling is perceived as an outdated technique by some
software engineers, it continues to be one of the most widely used requirements
analysis notations in use today.
Although the data flow diagram (DFD) and related diagrams and information
are not a formal part of UML, they can be used to complement UML diagrams and
provide additional insight into system requirements and flow.
The DFD takes an input-process-output view of a system. That is, data objects
flow into the software, are transformed by processing elements, and resultant data
objects flow out of the software.
Data objects are represented by labeled arrows, and transformations are
represented by circles (also called bubbles).
The DFD is presented in a hierarchical fashion.
That is, the first data flow model (sometimes called a level 0 DFD or context
diagram) represents the system as a whole.

CREATING A DATA FLOW MODEL

The data flow diagram enables you to develop models of the information
domain and functional domain.
As the DFD is refined into greater levels of detail, you perform an implicit
functional decomposition of the system.
Simple guidelines the derivation of a data flow diagram:-
The level 0 data flow diagram should depict the software/system as a
single bubble.
Primary input and output should be carefully noted.
Refinement should begin by isolating candidate processes, data objects,
and data stores to be represented at the next level.
All arrows and bubbles should be labeled with meaningful names.
Information flow continuity must be maintained from level to level.
One bubble at a time should be refined. There is a natural tendency to
overcomplicate the data flow diagram.
The refinement of DFDs continues until each bubble performs a
simple function.

That is, until the process represented by the bubble performs a function that
would be easily implemented as a program component. called cohesion.
CONTROL FLOW MODEL
For some types of applications, the data model and the data flow diagram are
all that is necessary to obtain meaningful insight into software requirements.
Such applications require the use of control flow modeling in addition to data
flow modeling.
The following guidelines are for select potential candidate events:
List all sensors that are “read” by the software.
List all interrupt conditions.
List all “switches” that are actuated by an operator.
List all data conditions.
Recalling the noun/verb parse that was applied to the processing
narrative, review all “control items” as possible control specification
inputs/outputs.
Describe the behavior of a system by identifying its states, identify how
each state is reached, and define the transitions between states.
Focus on possible omissions—a very common error in specifying
control; for example, ask: “Is there any other way I can get to this state
or exit from it?”
THE CONTROL SPECIFICATION
A control specification (CSPEC) represents the behavior of the system in
two different ways.
The CSPEC contains a state diagram that is a sequential specification of
behavior. It can also contain a program activation
table a combinatorial specification of behavior.
The CSPEC contains a state diagram that is a sequential specification of
behavior. It can also contain a program activation
table a combinatorial specification of behavior.
A somewhat different mode of behavioral representation is the process
activation table. The PAT represents information contained in the state diagram in the
context of processes, not states.
That is, the table indicates which processes (bubbles) in the flow model will be
invoked when an event occurs.
The PAT can be used as a guide for a designer who must build an executive
that controls the processes represented at this level.
The CSPEC describes the behavior of the system, but it gives us no information
about the inner working of the processes that are activated as a result of this behavior.
THE PROCESS SPECIFICATION
The process specification (PSPEC) is used to describe all flow model
processes that appear at the final level of refinement.
The content of the process specification can include narrative text, a program
design language (PDL) description of the process algorithm, mathematical
equations, tables, or UML activity diagrams.
DESIGN ENGINEERING
Design engineering encompasses the set of principles, concepts and practices
that lead to development of a high-quality system or product.
Design principles establish an overriding philosophy that guides the designer in
the work that is performed.
Design engineering is not a commonly used phrase in the software engineering
context.
The goal of design engineering is to produce a model or representation that
exhibits firmness, commodity and delight.
Design engineering for computer software changes continually as new
methods, better analysis, and broader understanding evolve.
To accomplish thus, a designer must practice diversification and the
convergence.
These qualities are based on experience in building similar entities, a set of
principles and heuristics that guide the way in which the model evolves, a set of
criteria that enables quality to be judged, and the process of iteration that ultimately
leads to a final design.
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.
Fundamental software design concepts provide the necessary framework for
“getting it right”.
There are several basic concepts are involved in designing concept in software
engineering
Abstraction
Architecture
Patterns
Modularity
Information hiding
Functional independence
Refinement
Refactoring
Design classes

ABSTRACTION
Abstraction is the act of representing essential features without including the
background details or explanations.
The abstraction is used to reduce complexity and allow efficient design and
implementation of complex software systems.
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.
At lower levels of abstraction, a more detailed description of the solution is
provided. As different levels of abstraction are developed, you work to create both
procedural and data abstractions.
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.
A data abstraction is a named collection of data that describes a data object.
ARCHITECTURE
Software architecture alludes to “the overall structure of the software and the
ways in which that structure provides conceptual integrity for a system” 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.
The goal of software design is to derive an architectural rendering of a system.
This rendering serves as a framework from which more detailed design activities
are conducted.
A set of architectural patterns enable a software engineer to reuse design- level
concepts.
Structural Models : Which represents architecture as an organized collection
of program components.
Framework models : increase the level of design abstraction by attempting to
identify repeatable architectural design framework 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 model : focus on the design of the business or technical process that
the system must accommodate.
Functional model : which can be used to represent the functional hierarchy of
a system.
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” .
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
whether the pattern is applicable to the current work,
whether the pattern can be reused (hence, saving design time), and
whether the pattern can serve as a guide for developing a similar, but
functionally or structurally different pattern.
MODULARITY
Modularity is the most common manifestation of separation of concerns.
Software is divided into separately named and addressable components,
sometimes called module.
Modularity is the single attribute of software that allows a program to be
intellectually manageable.
Modularity is achieved by dividing the software into uniquely named and
addressable components, which are also known as modules.
A complex system (large program) is partitioned into a set of discrete modules
in such a way that each module can be developed independent of other modules.
After developing the modules, they are integrated together to meet the software
requirements. Note that larger the number of modules a system is divided into, greater
will be the effort required to integrate the modules.
Modularizing a design helps to plan the development in a more effective manner,
accommodate changes easily, conduct testing and debugging effectively and efficiently,
and conduct maintenance work without adversely affecting the functioning of the
software.
INFORMATION HIDING
Information hiding is a software design principle, where certain aspects of a
program or module (the “secrets”) are inaccessible to clients.
The primary goal is to prevent extensive modification to clients whenever the
implementation details of a module or program are changed.
This is done by hiding aspects of an implementation that might change behind
a stable interface that protects clients from the implementation details.
Users of that interface (whether it is a module, class, or function) will perform
operations purely through its interface.
This way, if the implementation changes, the clients do not have to change.
Information hiding serves as a criterion that can be used to decompose a system into
modules. The principle is also useful for reducing coupling within a system.
Information hiding helps us improve the ability to change our system while
minimizing the impact on other parts of the system.
Since the implementation details are hidden behind a common interface,
changes to the implementation do not require changes to the rest of the program (as
long as the implementation sufficiently satisfies the specified interface).
Changes are isolated to a single location in the ideal case.
For example, a common sensor API may be provided, and any sensor driver
that satisfies the interface requirements can be used within the system. This enables a
team to swap between components (and even processors or board designs) as
necessary.
FUNCTIONAL INDEPENDENCE
Functional independence is achieved by developing functions that perform only
one kind of task and do not excessively interact with other modules.
Independence is important because it makes implementation more accessible and
faster.
The independent modules are easier to maintain, test, and reduce error
propagation and can be reused in other programs as well.
Thus, functional independence is a good design feature which ensures software
quality.
It is measured using two criteria:
o Cohesion:
Cohesion is a natural extension of the information hiding concept. It
measures the relative function strength of a module.
A cohesion module performs a single task, requiring little interaction with
other components in other parts of a program.
o Coupling:
Coupling is an indication of interconnection among modules in a software
structure.
It measures the relative interdependence among modules, the point at
which entry or reference is made to a module, and what data pass across the
interface.
REFINEMENT
Stepwise refinement is the idea that software is developed by moving through
the levels of abstraction, beginning at higher levels and, incrementally refining the
software through each level of abstraction, providing more detail at each increment.
At higher levels, the software is merely its design models; at lower levels there
will be some code; at the lowest level the software has been completely developed.
At the early steps of the refinement process the software engineer does not
necessarily know how the software will perform what it needs to do.
This is determined at each successive refinement step, as the design and the
software is elaborated upon.
Refinement can be seen as the compliment of abstraction.
Abstraction is concerned with hiding lower levels of detail; it moves from
lower to higher levels.
Refinement is the movement from higher levels of detail to lower levels. Both
concepts are necessary in developing software.
REFACTORING
Refactoring is the process of restructuring code, while not changing its original
functionality.
The goal of refactoring is to improve internal code by making many small
changes without altering the code's external behavior.
Computer programmers and software developers refactor code to improve the
design, structure and implementation of software.
Refactoring improves code readability and reduces complexities. Refactoring
can also help software developers find bugs or vulnerabilities hidden in their software.
The refactoring process features many small changes to a program's source
code.
One approach to refactoring, for example, is to improve the structure of source
code at one point and then extend the same changes systematically to all applicable
references throughout the program.
The thought process is that all the small, behavior-preserving changes to a body
of code have a cumulative effect.
These changes preserve the software's original behavior and do not modify its
behavior.
DESIGN CLASSES
A set of design classes refined the analysis class by providing design details.
1)Refine the analysis classes by providing design detail that will enable
the classes to be implemented.
2)Create a new set of design classes that implement a software
infrastructure to support the business solutions.
There are five different types of design classes and each type represents the
layer of the design architecture these are as follows:
1. User interface classes
These classes are designed for Human Computer Interaction(HCI).
These interface classes define all abstraction which is required for Human
Computer Interaction(HCI).
2. Business domain classes
These classes are commonly refinements of the analysis classes.
These classes are recognized as attributes and methods which are required to
implement the elements of the business domain.
3. Process classes
It implement the lower level business abstraction which is needed to
completely manage the business domain class.
4. Persistence classes
It shows data stores that will persist behind the execution of the software.
5. System Classes
System classes implement software management and control functions that
allow to operate and communicate in computing environment and outside
world.
The characteristic of well formed designed class are as follows:
1. Complete and sufficient
A design class must be the total encapsulation of all attributes and methods
which are required to exist for the class.
2. Primitiveness
The method in the design class should fulfil one service for the class.
If service is implemented with a method then the class should not provide
another way to fulfil same thing.
3. High cohesion
A cohesion design class has a small and focused set of responsibilities.
For implementing the set of responsibilities the design classes are applied
single-mindedly to the methods and attribute.
4. Low-coupling
All the design classes should collaborate with each other in a design model.
The minimum acceptable of collaboration must be kept in this model.

THE DESING MODEL

The design model can be viewed in two different dimensions.

The process dimension represents the evolution of the design model as design
tasks are executed as part of the software process.
The abstraction dimension represents the level of detail as each element of the
analysis model is transformed into a design equivalent and then refined iteratively.
Design modeling in software engineering represents the features of the software
that helps engineer to develop it effectively, the architecture, the user interface, and the
component level detail.
Design modeling provides a variety of different views of the system like
architecture plan for home or building.
Different methods like data-driven, pattern-driven, or object-oriented methods
are used for constructing the design model.
All these methods use set of design principles for designing a model.

DATA DESIGN ELEMENTS :

The data design element produced a model of data that represent a high level
of abstraction.
This model is then more refined into more implementation specific
representation which is processed by the computer based system.
The structure of data is the most important part of the software design.
The structure of data has always been an important part of software design.
o At the program component level, the design of data structures and the
associated algorithms required to manipulate them is essential to the
creation of high-quality applications.
o At the application level, the translation of a data model into a database
is pivotal to achieving the business objectives of a system.
o At the business level, the collection of information stored in disparate
database and reorganized into a data warehouse enables data mining or
knowledge discovery that can have an impact on the success if the
business itself.

ARCHITECTURAL DESIGN ELEMENT

Architectural design elements give us an overall view of the software
The architectural model us derived from three sources.
1) Information about the application domain for the software to be built.
2) Specific analysis model elements such as data flow diagrams or
analysis classes, their relationships and collaborations for the problem at hand
3) The availability of architectural patterns and styles.
INTERFACE DESIGN ELEMENT
It represents how the Software communicates with the user i.e. the behavior of
the system.
It refers to the product where user interact with controls or displays of the
product.
For example, Military, vehicles, aircraft, audio equipment, computer
peripherals are the areas where user interface design is implemente
UI design becomes efficient only after performing usability testing. This is
done to test what works and what does not work as expected.
Only after making the repair, the product is said to have an optimized interface.
The user interface is the main thing of any software
No matter how good its internal functions are or how well designed its
architecture is but if the user interface is poor and end-users don’t feel ease to handle
the software then it leads to the opinion that the software is bad.
There are three important elements of interface design :
1) The user interface (UI)
2) External interface (system, devices, networks, other producers)
3) Internal interface (various design components)
The design of UI incorporates aesthetic elements (layout, color, graphics),
ergonomic elements (information layout, placement, UI navigation), technical elements
(UI patterns, reusable components)
The UI is unique subsystem within the overall application architecture.

UML interface representation for control panel

The interaction diagram helps to envision the interactive (dynamic) behavior of any
system. It portrays how objects residing in the system communicates and connects to
each other. It also provides us with a context of communication between the lifelines
inside the system.
Following are the purpose of an interaction diagram given below:
1. To visualize the dynamic behavior of the system.
2. To envision the interaction and the message flow in the system.
3. To portray the structural aspects of the entities within the system.
4. To represent the order of the sequenced interaction in the system.
5. To visualize the real-time data and represent the architecture of an object-
oriented system.
COMPONENT LEVEL DESIGN ELEMENTS
A component diagram is used to break down a large object-oriented system into
the smaller components, so as to make them more manageable.
It models the physical view of a system such as executables, files, libraries, etc.
that resides within the node.
It visualizes the relationships as well as the organization between the components
present in the system. It helps in forming an executable system.
A component is a single unit of the system, which is replaceable and executable.
The implementation details of a component are hidden, and it necessitates an interface
to execute a function.
It is like a black box whose behavior is explained by the provided and required
interfaces.
The main purpose of the component diagram are enlisted below:
1. It envisions each component of a system.
2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.
Following are some reasons, which tells when to use component diagram:
1. To divide a single system into multiple components according to the
functionality.
2. To represent the component organization of the system.
The component diagram can be used for the followings:
1. To model the components of the system.
2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.

DEPLOYMENT – LEVEL DESIGN ELEMENT

The deployment diagram visualizes the physical hardware on which the software
will be deployed. It portrays the static deployment view of a system. It involves the
nodes and their relationships.
It ascertains how software is deployed on the hardware. It maps the software
architecture created in design to the physical system architecture, where the software
will be executed as a node.
Since it involves many nodes, the relationship is shown by utilizing
communication paths.
The main purpose of the deployment diagram is to represent how software is
installed on the hardware component. It depicts in what manner a software interacts
with hardware to perform its execution.
Both the deployment diagram and the component diagram are closely
interrelated to each other as they focus on software and hardware components.
The component diagram represents the components of a system, whereas the
deployment diagram describes how they are actually deployed on the hardware.
Deployment diagrams can be used for the followings:
1. To model the network and hardware topology of a system.
2. To model the distributed networks and systems.
3. Implement forwarding and reverse engineering processes.
4. To model the hardware details for a client/server system.
5. For modeling the embedded system.

MODELING COMPONENT – LEVEL DESIGN

Component-based architecture focuses on the decomposition of the design into
individual functional or logical components that represent well-defined communication
interfaces containing methods, events, and properties.
It provides a higher level of abstraction and divides the problem into sub-
problems, each associated with component partitions.
The primary objective of component-based architecture is to ensure component
reusability.
A component encapsulates functionality and behaviors of a software element
into a reusable and self-deployable binary unit.
There are many standard component frameworks such as COM/DCOM,
JavaBean, EJB, CORBA, .NET, web services, and grid services.
These technologies are widely used in local desktop GUI application design such
as graphic JavaBean components, MS ActiveX components, and COM components
which can be reused by simply drag and drop operation.
Component-oriented software design has many advantages over the traditional
object-oriented approaches such as −
• Reduced time in market and the development cost by reusing existing
components.
• Increased reliability with the reuse of the existing components.
What is a Component?
A component is a modular, portable, replaceable, and reusable set of well-
defined functionality that encapsulates its implementation and exporting it as a higher-
level interface.
A component is a software object, intended to interact with other components,
encapsulating certain functionality or a set of functionalities. It has an obviously defined
interface and conforms to a recommended behavior common to all components within
an architecture.
A software component can be defined as a unit of composition with a
contractually specified interface and explicit context dependencies only. That is, a
software component can be deployed independently and is subject to composition by
third parties.
Object-oriented view
A component is viewed as a set of one or more cooperating classes.
Each problem domain class (analysis) and infrastructure class (design) are explained
to identify all attributes and operations that apply to its implementation.
It also involves defining the interfaces that enable classes to communicate and
cooperate.
In the context of object-oriented software engineering, a component contains a
set of collaborating classes.
Each class within a component has been fully elaborated to include all
attributes and operations that are relevant to its implementation.
As part of the design elaboration, all interfaces that enable the classes to
communicate and collaborate with other design classes must also be defined.
To accomplish this, you begin with the requirements model and elaborate
analysis classes (for components that relate to the problem domain)
Explanation of Figure :

To illustrate this process of design elaboration, consider software to be built for

a sophisticated print shop.
The overall objective of the software is to collect the customer’s requirements
at the front counter, cost a print job, and then pass the job on to an automated
production facility.
During requirements engineering, an analysis class called PrintJob was derived.
The attributes and operations defined during analysis are noted at the top of Figure.
During architectural design, PrintJob is defined as a component within the
software architecture and is represented using the shorthand UML notation shown in
the middle right of the figure.
Note that PrintJob has two interfaces, computeJob, which provides job costing
capability, and initiateJob, which passes the job along to the production facility. These
are represented using the “lollipop” symbols shown to the left of the component box.
Component-level design begins at this point. The details of the component
PrintJob must be elaborated to provide sufficient information to guide
implementation. The original analysis class is elaborated to flesh out all attributes and
operations required to implement the class as the component PrintJob.
Conventional view
It is viewed as a functional element or a module of a program that integrates the
processing logic, the internal data structures that are required to implement the
processing logic and an interface that enables the component to be invoked and data to
be passed to it.
In the context of traditional software engineering, a component is a functional
element of a program that incorporates
Processing logic,
The internal data structures that are required to implement the processing
logic,
An interface that enables the component to be invoked and data to be passed to
it.
A traditional component, also called a module, resides within the software
architecture and serves one of three important roles:
(1) A control component that coordinates the invocation of all other
problem domain components,
(2) A problem domain component that implements a complete or
partial function that is required by the customer,
(3) An infrastructure component that is responsible for functions that
support the processing required in the problem domain.

Structure chart for a conventional system

Process-related view

In this view, instead of creating each component from scratch, the system is building
from existing components maintained in a library.
As the software architecture is formulated, components are selected from the library
and used to populate the architecture.
• A user interface (UI) component includes grids, buttons referred as controls, and
utility components expose a specific subset of functions used in other
components.
• Other common types of components are those that are resource intensive, not
frequently accessed, and must be activated using the just-in-time (JIT) approach.
• Many components are invisible which are distributed in enterprise business
applications and internet web applications such as Enterprise JavaBean (EJB),
.NET components, and CORBA components.
• Assume that the component is being designed from scratch or used an existing
components for new development.
• That is, you have to create a new component based on specifications derived
from the requirements model.
• There is, of course, another approach.
• The software engineering community has emphasized the need to build systems
that make use of existing software components or design patterns.
• In essence, a catalog of proven design or code-level components is made
available to you as design work proceeds.
• As the software architecture is developed, you choose components or design
patterns from the catalog and use them to populate the architecture.
• Because these components have been created with reusability in mind, a
complete description of their interface, the function(s) they perform, and the
communication and collaboration they require are all available to you.

DESIGNING CLASS – BASED COMPONENTS

Component – level design draws on information developed as part of the analysis

model. It focus on
• Draws on information developed as part of the requirements
model
• Represented as part of the architectural model.
When an object-oriented software engineering approach is chosen, component-
level design focuses on the elaboration of problem domain specific classes
The definition and refinement of infrastructure classes contained in the
requirements model.
The detailed description of the attributes, operations, and interfaces used by
these classes is the design detail.
BASIC DESIGN PRINCIPLES
1) The Open-Closed Principle (OCP).
“A module [component] should be open for extension but closed for
modification”
✓ Design should specify the component in a way that allows it to be extended
(within the functional domain that it addresses) without the need to make
internal (code or logic-level) modifications to the component itself.
✓ To accomplish this, you create abstractions that serve as a buffer between the
functionality that is likely to be extended and the design class itself.
✓ For example : assume that the Safe Home security function makes use of a
Detector class that must check the status of each type of security sensor. It is
likely that as time passes, the number and types of security sensors will grow.
✓ If internal processing logic is implemented as a sequence of if-then-else
constructs, each addressing a different sensor type, the addition of a new sensor
type will require additional internal processing logic (still another if-then-else).
This is a violation of OCP.
✓ One way to accomplish OCP for the Detector class is illustrated in Figure 1.
The sensor interface presents a consistent view of sensors to the detector
component. If a new type of sensor is added no change is required for the
Detector class (component). The OCP is preserved
2) The Liskov Substitution principle (LSP)
“Subclasses should be substitutable for their base classes”.
✓ It suggests that, a component that uses a base class should continue to function
properly if a class derived from the base class is passed to the component
instead.
✓ LSP demands that any class derived from a base class must honor any implied
contract between the base class and the components that use it
✓ In the context of this discussion, a “contract” is a precondition that must be true
before the component uses a base class and a post condition that should be true
after the component uses a base class.
✓ When you create derived classes, be sure they conform to the pre and post
conditions.
3) Dependency Inversion Principle (DIP).
“Depend on abstractions. Do not depend on concretions.”
✓ Here abstractions are the place where a design can be extended without
great complication.
✓ The more a component depends on other concrete components (rather than
on abstractions such as an interface), the more difficult it will be to extend.
4) The Interface Segregation (Separation) Principle (ISP).
“Many client-specific interfaces are better than one general purpose
interface.
✓ There are many instances in which multiple client components use the
operations provided by a server class.
✓ ISP suggests that, you should create a specialized interface to serve each
major category of clients. Only those operations that are relevant to a
particular category of clients should be specified in the interface for that
client.
✓ If multiple clients require the same operations, it should be specified in each
of the specialized interfaces.
5) The Release Reuse Equivalency Principle (REP).
“The granule of reuse is the granule of release.”
✓ When classes or components are designed for reuse, there is an implicit
contract that is established between the developer of the reusable entity and the
people who will use it.
✓ The developer commits to establish a release control system that supports and
maintains older versions of the entity while the users slowly upgrade to the
most current version.
✓ Rather than addressing each class individually, it is often advisable to group
reusable classes into packages that can be managed and controlled as newer
versions evolve
6) The Common Closure Principle (CCP).
“Classes that change together belong together.”
✓ Classes should be packaged cohesively.
✓ That is, when classes are packaged as part of a design, they should address
the same functional or behavioral area.
✓ When some characteristic of that area must change, it is likely that only
those classes within the package will require modification.
7) The Common Reuse Principle (CRP).
“Classes that aren’t reused together should not be grouped together.”
✓ Classes that are reused together should be included within a package.
✓ All other classes or packages that rely on the package that has been changed
must now updated to the most recent release of the package.
✓ It to be tested to ensure that the new release operates without incident.