Design Engineering is a topic of software engineering of second year fourth semester

Unit 3
DesignEngineering
Course: Software Engineering andProject
Management

S
yllabus
Design Process& quality, DesignConcepts, Thedesign Model, Pattern-
based Software Design.
Architectural Design:Design Decisions, Views, Patterns,Application
Architectures
Modeling Componentlevel Design:component, Designing classbased
components, conducting component-level design
UserInterface Design: Thegolden rules, Interface Designsteps &
Analysis, Design Evaluation
CaseStudy:WebApp InterfaceDesign

 Software design encompasses the set of principles, concepts, and
practicesthat lead to the development of a high-quality system
or product.
What isdesign ?
 Design is what almost every engineer wants to do. It is the place
where creativity rules—where stakeholder requirements,
business needs, and
technicalconsiderations all come together in the
formulation of aproduct orsystem.
 Design creates a representation or model of the software, but
unlike the requirements model (that focuses on describing
required data, function, and behavior), the design model provides
detail about software architecture, data structures, interfaces,and
components that are necessary toimplement the system.

DesignProcess
 Software design is an iterative process through whichrequirements
are translated into a―blueprint‖ for constructing the software.
SoftwareQuality GuidelinesandAttributes
 Throughout the design process, the quality ofthe evolving design is
assessedwith aseries of technical reviews suggeststhree
characteristics that serve asaguide for the evaluation of agood
design:
1. Thedesign must implement all of the explicit requirements
contained in the requirements model, and it must accommodate all
of the implicitrequirements desired by stakeholders.
2. The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.

3. Thedesign should provide acomplete picture of the software,
addressing the data, functional, and behavioral domains froman
implementation perspective.
 Eachof these characteristics is actually agoal of the designprocess.
Quality Guidelines
 In order to evaluate the quality of a design representation, you
and other members of the software team must establish
technical criteria for good design.
 Considerthe followingguidelines :-
1. Adesign should exhibit an architecture that (1) hasbeen created
using recognizable architectural styles or patterns, (2) is composed
of components that exhibitgood design characteristics, and (3) can
be implemented in an evolutionary fashion, 2 thereby facilitating
implementation andtesting.

2. Adesign should be modular; that is, the softwareshould be logically
partitioned into elements orsubsystems.
3. Adesign should contain distinct representations of data,
architecture, interfaces, andcomponents.
4. Adesign should lead todata structures that are appropriate for the
classesto be implemented and are drawn from recognizable data
patterns.
5. Adesign should lead to components that exhibitindependent
functional characteristics.
6. Adesign should lead to interfaces thatreduce the complexity of
connections between components and with the external
environment.

7. Adesign should be derived using arepeatable method that isdriven
by information obtained during software requirementsanalysis.
8. Adesign should be represented using anotation that effectively
communicates its meaning.
QualityAttributes
 Hewlett-Packard [Gra87] developed aset of software quality
attributes that hasbeen given the acronymFURPS—functionality,
usability, reliability, performance, and supportability.
 TheFURPSquality attributes represent atarget for all software
design:

Functionalityis assessedby evaluating the feature set and
capabilities of the program, the generality of the functions that are
delivered, and the security of theoverall system.
Usability is assessedby considering human factors,overall
aesthetics, consistency, anddocumentation.
Reliability is evaluated by measuring the frequency and severityof
failure, the accuracy of output results, the mean-time-to-failure
(MTTF),the ability to recover from failure, and the predictability of
the program.
Performanceis measured by considering processing speed,
response time, resource consumption, throughput, andefficiency.

Supportability combines the ability to extend the program
(extensibility), adaptability, serviceability—these three attributes
represent amore common term, maintainability —and in addition,
testability, compatibility, configurability, the easewith whichasystem
canbe installed, and the easewith which problems can belocalized.

Figure8.1 : Translatingthe requirements model into the design mode

1. Abstraction
 When you consider amodular solution to any problem,many levels
of abstraction canbeposed.
 At the highest level of abstraction, asolution is stated in broad terms
using the language of the problem environment.
 At lower levels of abstraction, amore detailed description ofthe
solution isprovided.
 Finally, at the lowest level of abstraction, the solution is stated in a
manner that can be directlyimplemented.
 Aproceduralabstractionrefers to asequence of instructions
that have aspecific and limited function.
 Thename of aprocedural abstraction implies these functions,but
specific details aresuppressed.

 An example of aprocedural abstraction would be the word openfora
door.
 Openimplies 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.).
 Adata abstractionis anamed 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
aset of attributes that describe the door(e.g., door type, swing
direction, opening mechanism, weight, dimensions).
 It follows that the procedural abstraction openwould make useof
information contained in the attributes of the data abstraction door.

2. Architecture
 Software architecture alludes (signals) to ―the overall structure of the
software and the waysin which that structure provides conceptual
integrity for asystem‖.
 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.
 There is aset of properties that should be specified aspart ofan
architectural design.

Structural properties : Thisaspect of the architecturaldesign
representation defines the components of a system (e.g.,
modules, objects, filters) and the manner in which those
components are packaged and interact with oneanother.
 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 architectureachieves
requirements for performance, capacity, reliability, security,
adaptability, and other systemcharacteristics.

Familiesof related systems: Thearchitectural design should
draw upon repeatable patterns thatare commonly encountered in
the design of families of similar systems. In essence,the design
should have the ability toreuse architectural building blocks.
 Given the specification of these properties, the architectural
design can be representedusingoneormoreof a numberof
different models.
 Structural models represent architecture as an organized collection
of program components.
 Framework models increase the level of design abstraction by
attempting toidentify 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 afunction of external events.
 Process models focus on the design of the business or technical
process that the systemmustaccommodate.
 Functional models can be used to represent the functionalhierarchy
of asystem.
 Anumber of different architectural description languages (ADLs)have
been developed to represent thesemodels.

3. Patterns
 ― Apattern is anamed nugget of insight which conveys theessence
of aproven solution to arecurring problem within acertain context
amidst competing concerns‖.
 Adesign pattern describes adesign structure that solves aparticular
design problem within aspecific 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 adesigner to determine
(1) whether the pattern is applicable to the current work,
(2) whether the pattern canbe reused (hence, saving designtime),
(3) whether the pattern canserve asaguide for developing asimilar,
butfunctionally or structurally different pattern.

4. Separationof Concerns
 Separation of concerns is a design concept that suggests that any
complex problem canbe more easily handled if it is subdivided into
pieces that caneachbe solved and/or optimized independently.
 Aconcern is a feature or behavior that is specified aspart of the
requirements model for thesoftware.
 Byseparating concerns into smaller, and therefore moremanageable
pieces, aproblem takes lesseffort and time tosolve.
 For two problems, p1 and p2, if the perceived complexity of p1 is
greater than the perceived complexity of p2 , it follows that the effort
required to solve p1 is greater than the effort required to solve p2.

 Asageneral case,this result is intuitively obvious. It does takemore
time to solve adifficultproblem.
 It also follows that the perceived complexity of two problems when
they are combined is often greater than the sum of the perceived
complexity when each is takenseparately.
 Thisleads to adivide-and-conquer strategy—it‘s easier to solve a
complex problem when you break itinto manageable pieces. Thishas
important implications with regard to software modularity.

5. Modularity
 Modularity is the most common manifestation of separation of
concerns.
 Software is divided into separately named and addressable
components, sometimes called modules, that are integratedto
satisfy problem requirements.
 Monolithic software (i.e., alarge program composed ofasingle
module) cannot be easily grasped by asoftwareengineer.
 The number of control paths, span of reference, number of variables,
and over-all complexity would make understanding close to
impossible.
 In almost all instances, you should break the design intomany
modules, hoping to make understanding easier and, asa
consequence, reduce the cost required tobuild the software.

 Referring to Figure 8.2, the effort (cost) to develop an individual
software module does decrease asthe total number of modules
increases.
 Given the sameset of requirements, more modules meanssmaller
individual size.
 However, asthe number of modules grows, the effort(cost)
associated with integrating the modulesalso grows.
 These characteristics lead to atotal cost or effort curve shown in the
figure.
 There is anumber, M, of modules that would result in minimum
development cost, but we do not have thenecessary sophistication
to predict M with assurance.

Figure8.2 : Modularity andsoftware cost

 Y
oumodularize adesign (and the resulting program) sothat
development canbe more easilyplanned;
 Software increments canbe defined anddelivered;
 Changescan be more easily accommodated; testing anddebugging
canbe conducted more efficiently, and
 Long-term maintenance canbe conducted without seriousside
effects.

6. Information Hiding
 Theprinciple of information hiding suggests thatmodules be
―characterized by design decisions that (each) hides fromall others. ‖
 Modules should be specified and designed sothat information
(algorithms and data) contained within amodule is inaccessibleto
other modules that have no need forsuchinformation.
 Hiding implies that effective modularitycanbe 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 thesoftware.
 Hiding defines and enforces accessconstraints to bothprocedural
detail within amodule and any local data structure used by the
module.

 The use of information hiding asa design criterion for modular
systems provides the greatest benefits when modifications are
required during testing & later during software maintenance.
 Because most data & procedural detail are hidden from other parts of
the software, errors introduced during modification are lesslikely to
prepare to other locations within the software.

7. Functional Independence
 Functional independence is achieved by developing modules.
 Y
oushould design software sothat each module addressesaspecific
subset of requirements & hasasimple interface when viewed from
other parts of theprogram structure.
 Software with effective modularity, that is, independent modules, is
easier to develop becausefunction canbe compartmentalized &
interfaces aresimplified.
 Independent modules are easier to maintain (& test) because
secondary effects causedby design or code modifications arelimited,
error propagation is reduced, & reusable modulesare possible.
 Independence is assessedusing two qualitative criteria : cohesion&
coupling.

 Cohesionis an indication of the relative functional strength ofa
module.
 Couplingis an indication of the relative interdependenceamong
modules.
 Cohesion is anatural extension of theinformation-hiding.
 Cohesive module performs asingle task, requiring little interaction
with other components in other parts of aprogram.
 Cohesive module should do just one thing.
 Coupling is an indication of interconnection among modules ina
software structure.
 Coupling depends on the interface complexity betweenmodules, the
point at which entry or reference is made to amodule, & what data
passacrossthe interface.

 In software design, you should strive forthe lowest possible coupling.
 Simple connectivity among modules results in software thatis easier
to understand & less prone to a―ripple effect‖, causedwhen errors
occur at one location & propagate throughoutasystem.

8. Refinement
 Stepwise refinement is atop-down designstrategy.
 Ahierarchy is developed by decomposing amacroscopic statement of
function in astepwise fashion until programming language
statements arereached.
 Refinement is actually aprocess of Elaboration.
 Y
oubegin with astatement of function thatis defined at ahigh level
of abstraction.
 That is, the statement describes function or informationconceptually
but provides noinformation.
 Y
outhen elaborate on the original statement, providing more & more
detail aseach successiverefinement (elaboration) occurs.

9. Aspects
 It is important to identify aaspects so that the design can properly
accommodate them asrefinement & modularizationoccur.

10. Refactoring
 Refactoring is areorganization technique that simplifies thedesign
(or code) of acomponent without changing its function or behavior.
 Refactoring is the process of changing asoftware system in sucha
way that it does not alter the external behavior of the code (design)
yet improves its internalstructure.
 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 iteration might yield acomponent that exhibits low
cohesion.
 After careful consideration, you may decide that the component
should be refactored into 3 separate components, eachexhibiting
high cohesion.
 The result will be software that is easier to integrate, easier to test, &
easier to maintain.

11. Object Oriented DesignConcepts
 TheOOparadigm is widely used in modern software engineering.
 OOconcepts such asClasses& objects, inheritance, message&
polymorphism, amongothers.

12. DesignClasses
 Therequirement model defines aset of analysisclasses.
 Eachdescribes some element of the problem domain, focusingon
aspects of the problem thatare user visible.
 Thelevel of abstraction of an analysis classis relativelyhigh.
 Asthe design model evolves, you will define aset ofdesignclasses
that refine the analysis classesby providing design detail that will
enable classesto beimplemented.
 5 different types of design classes,each representing adifferentlayer
of the design architecture, can be developed:-
1. UserInterface Classes:- Define all abstractions that are necessary
for Human Computer Interaction(HCI).
2. BusinessDomainClasses:- Are often refinements of the analysis
classesdefined earlier. Theclassesidentify the attributes &services
(methods) that are required to implement some element of the
business domain.

3. ProcessClasses:- Implement lower-level business abstractions
required to fully manage thebusiness domain classes.
4. Persistent Classes:- Represent data stores (e.g. adatabase) that will
persist beyond the execution of thesoftware.
5. SystemClasses:- Implement software management & control
functions that enable the system to operate & communicate within
its computing environment & with the outside world.
 4 Characteristics of awell-formed design class:-
1. Complete& sufficient :- Adesign classshould be complete
encapsulation of all attributes & methods that can reasonably be
expected to exist for aclass.

 For example, the classScenedefined for video-editing softwareis
complete only if it contains all attributes & methods that can
reasonably be associated with the creation ofavideo scene.
 Sufficiently ensures that the design classcontains only thosemethods
that are sufficiently to achieve the intent of the class,no more & no
less.
2. Primitiveness :- Methods associated with adesign classshould be
focused on accomplishing one service for theclass.
 Oncethe service hasbeen implemented with amethod, theclass
should not provide another way toaccomplish the samething.
 For example, the classVideoClipfor video-editing software might
have attributes start-point and end-pointto indicate the start &end
points of theclip.
 Themethods, setStartPoint() & setEndPoint(),provide the only
means for establishing start & end points for the clip.

3. HighCohesion:- Acohesive design classhasasmall, focused set of
responsibilities & single-mindedly applies attributes & methods to
implement thoseresponsibilities.
 For example, the classVideoClipmight contain aset of methodsfor
editing the videoclip.
4. LowCoupling:- It is necessary for design classesto collaboratewith
one another.
 However, collaboration should be kept to an acceptableminimum.
 If adesign model is highly coupled, the systemis difficultto
implement, to test, & to maintain over time.
 In general, design classeswithin asubsystem should have only limited
knowledge of other classes.

Figure8.3 : Designclassfor FloorPlan& compositeaggregationfor the
class

Figure8.4 : Dimensionsof the Design Model

1. Data DesignElements
 Data design creates amodel of data &/or information that is
represented at ahigh level of abstraction (the customer / user‘s view
of data).
 Thisdata model is then refined into progressively more
implementation-specific representations that can be processedby
the computer-basedsystem.
 Thestructure of data hasalways been an important part ofsoftware
design.
 At the program component level, the design of data structures & the
associated algorithms required to manipulate them is essential to the
creation of high-qualityapplications.
 At the application level, the translation of adata model into a
database is pivotal to achieving the business objectives ofasystem.
 At the business level, the collection of information stored in disparate
databases & reorganized into a―data warehouse‖ enables data
mining.

2. Architectural Design Elements
 The architectural design for software is the equivalent to the floor
plan of ahouse.
 Thefloor pan depicts the overall layout of the rooms; their size,
shape, & relationship to one another; & the doors & windows that
allow movement into & out of the rooms.
 Thefloor plan gives usan overall view of thehouse.
 Architectural design elements give usan overall view of thesoftware.
 Thearchitectural model is derived from 3 sources:-
1. Information about the application domain for the software to be
built.
2. Specific requirements model elements suchasdata flow diagramsor
analysis classes,their relationships & collaborations for the problem
at hand.
3. Theavailability of architectural styles &patterns.

3. Interface DesignElements
 Theinterface design for software is analogous to aset ofdetailed
drawings for the doors, windows, & external utilities of ahouse.
 There are 3 important elements of interfacedesign:-
1. Theuser interface (UI).
2. External interfaces to other systems, devices, networks, orother
producers or consumers ofinformation.
3. Internal interfaces between various designcomponents.
 Theseinterface design elements allow the software tocommunicate
externally & enable internal communication & collaboration among
the components that populate thesoftware architecture.
 UI design increasingly called UsabilityDesign.

 Usability design incorporates aesthetic elements (e.g. layout, color,
graphics, metaphors, UI navigation), and technical elements (e.g. UI
patterns, reusable components).
 UI is unique subsystem within overall applicationarchitecture.
 Thedesign of external interfaces requires definitiveinformation
about the entity to which information is sent or received.
 In every case,this information should be collectedduring
requirements engineering.
 Thedesign of external interfaces should incorporate errorchecking &
appropriate security features.
 Thedesign of internal interfaces is closely aligned withcomponent-
level design.

 For example, the SafeHome()security function makesuseof acontrol
panel that allows ahomeowner to control certain aspects of the
security function.
 In an advanced version ofthe system, control panel functions may be
implemented via awireless PDAor mobile phone.
 TheControlPanel class(asFigure 8.5) provides the behavior
associated with akeypad, & therefore, it must implement the
operations readKeyStroke()and decodeKey().
 If these operations are to be provided to other classes(in this case,
WirelessPDAand MobilePhone), it is useful to define an interfaceas
shown in Figure8.5.

 Theinterface, named KeyPad,is shown asan <<interface >>
stereotype or asasmall, labeled circle connected to the class with a
line.
 The interface is defined with no attributes & the set of operations
that are necessary toachieve the behavior of akeypad.
 The dashed line with an open triangle at its end (Figure 8.5) indicates
that the controlPanel classprovides KeyPadoperations aspart of its
behavior.
 In UML, this is characterized asaRealization.
 That is, part of the behaviorof ControlPanel will be implementedby
realizing KeyPadoperations.
 Theseoperations will be provided to other classesthataccessthe
interface.

Figure8.5 : Interface representation for Control-Panel

4. Component-LevelDesign Elements
 Thisdesign is the equivalent to aset ofdetailed drawings (&
specifications) for each room in ahouse.
 These drawings depict writing & plumbing within each room, the
location of wall switches, faucets, sinks showers, tubs, drains,
cabinets, & closets.
Figure8.6 :AUMLComponentDiagram

 Thecomponent-level design for software fully describes theinternal
detail of each softwarecomponent.
 T
oaccomplish this, the component-level design defines data
structures for all local data objects & algorithmic detail for all
processing that occurs within acomponent & an interface that allows
accessto all component operations(behaviors).
 Acomponent is represented in UMLdiagrammatic form asshownin
Figure 8.6.
 In this Figure 8.6, acomponent named SensorManagament (partof
Safehomesecurity function) isrepresented.
 Adashed arrow connects the component to aclassnamedSensor
that is assigned to it.
 TheSensorManagement component performs all functions
associated with SafeHomesensors including monitoring &
configuring them.

4. Deployment-Level DesignElements
 It indicates how software functionality & subsystems will be allocated
within the physical computing environment that will support the
software.
 For example, the elements of the SafeHomeproduct are configured
tooperate within 3 primary computing environments – ahome based
PC,the SafeHomecontrol panel, & aserver housed at CPIcorp.
(providing internet based accessto thesystem).
 During design, aUMLdeployment diagram is developed & then
refined asFigure 8.7.
 Thesubsystems (functionality) housed within eachcomputing
element areindicated.
 For example, personal computer houses subsystems that implement
security, surveillance, home management, & communication
features.

Figure8.7 :AUMLdeploymentdiagram

 Thediagram shown in Figure 8.7 is in descriptorform.
 Thismeans that the deployment diagram shows the computing
environment but does not explicitly indicate configuration details.
 For example, the ―personal computer‖ is not further identified.
 It could be aMac or Windows-based PC,aSunworkstation, or a
Linux-box.

Requirements
Model
Consider
Design concepts
Extract
Problem, context
forces
Consider
Designquality
attributes
Begin
Pattern-based
Design tasks
Apply other
designmethods
And notation
Design model
Addressedby
Pattern ?
yes no
DesignBegins
Figure8.2 :
Pattern-
based design
in context

 The role of Pattern based design in all of this is asFigure 8.2
 Asoftware designer begins with arequirements model (either
explicit or implied) that presents an abstract representation of the
system.
 Therequirements model describes the problem set, establishes the
context, & identifies the system of forces that hold sway (influence).

DesignTasks
 Thefollowing design tasks are applied when apattern baseddesign
philosophy is used :-
1. Examine the requirements model & develop a problem hierarchy :-
Describe each problem & sub problem by isolating the problem, the
context, & the system of forces that apply.
 Work from broad problems (high level of abstraction) to smaller sub
problems (at lower levels ofabstraction).
2. Determine if a reliable pattern languagehasbeendevelopedfor
the problem domain:- APattern language addresses problems
associated with aspecific applicationdomain.
 If that level of pattern language specifically could not be found, the
team would partition the SafeHome software problem into aseries of
generic problem domains.

3. Beginningwith a broadproblem, determine whether oneor more
architectural patterns isavailablefor it :-
 If an architectural pattern is available, be certain to examine all
collaborating patterns.
4. Using the collaborations provided for the architectural pattern,
examine subsystem or component-level problems & search for
appropriatepatterns to addressthem.
 It may be necessary to search through other pattern responsible as
well asthe list of patterns that corresponds to the architectural
solution.
 If an appropriate pattern is found, adapt thedesign solution
proposed & build adesign model element that adequately
represents.

5. Repeatsteps2 through5 until all broadproblemshavebeen
addressed:-
 The implication is to begin with big picture & elaborate to solve
problems at increasingly more detailedlevels.
6. If userinterface designproblemshavebeenisolated (this isalmost
alwaysthe case),searchthe manyuserinterface designpattern
repositoriesfor appropriate patterns :-
 Proceed in amanner similar to steps 3,4 &5.
7. Regardlessof itslevel of abstraction, if a pattern languageand/or
patterns repositoryor individual patterns showpromise, compare
the problem to besolvedagainstthe existingpatterns(s)
presented:-
 Becertain to examine context & forces to ensure that the pattern
does, in fact, provide asolution that is amenable to the problem.

8. Becertain to refine the designasit isderived from patterns using
designquality criteria asa guide:-
BuildingPattern OrganizingTable
 Aspattern-based design proceeds, you may encounter trouble in
organizing &categorizing candidate patterns from multiple pattern
languages & repositories.
 T
o help organize your evaluation of candidate patterns, Microsoft
suggests the creation of a Pattern-Organizing table that takes the
general form show in Figure12.2

Database Application Implementation Infrastructure
Data/Content
Problem Statement… PatternName (s) PatternName (s)
Architecture
Problem Statement… PatternName (s)
Problem Statement…
Component-level
Problem Statement… PatternName (s)
User Interface
Figure12.2 :- Apattern organizingtable

 Apattern organizing table canbe implemented asaspreadsheet
model using the form shown in the Figure 12.2.
 An abbreviated list of problem statements, organized by
data/content, architecture, component-level, & user interfaceissues,
is presented in the left-hand (shaded)column.
 Four Pattern types – database, application, implementation,&
infrastructure – are listed acrossthe toprow.
 The names of candidate patterns are noted in the cells of the table.
 T
oprovide entries for the organizing table, you‘ll searchthrough
pattern languages & repositories for patterns that address a
particular problem statement.
 When one or more candidate patterns is found, it is entered in the
row corresponding to the problem statement & the column
corresponds to the patterntype.

CommonDesign Mistakes
 In some cases, not enough time has been spent to understand the
underlying problem & asa consequence, you select a pattern that
looks right but is inappropriate for the solution required.
 Once the wrong pattern is selected, you refuse to seeyour error &
force-fit the pattern.
 In other cases,the problem has forces that are not considered by the
pattern you have chosen, resulting in poor or erroneous fit.
 Sometimes apattern is applied too literally & the required adaptions
for your problem spaceare notimplemented.

 Architectural designis concerned with understanding how a
system should be organized and designing the overall structure of
that system.
 Theoutput of the architectural design process is anarchitectural
model that describes how the system is organized asaset of
communicating components.
 Y
oucan design software architectures at two levels ofabstraction,
which called asarchitecture in the smallandarchitecture in the
large:

1. Architecture in the small is concerned with the architecture of
individual programs.
 At this level, we are concerned with the way that an individual
program is decomposed into components.
2. Architecture in the large is concerned with the architecture of
complex enterprise systemsthat include othersystems, programs,
and program components.
 Theseenterprise systemsare distributed over different computers,
which may be owned and managed by different companies.

Figure6.1 : Thearchitecture of a packingrobot control system

 Systemarchitectures are often modeled using simple blockdiagrams,
asin Figure6.1.
 Eachboxin the diagram represents acomponent.
 Boxeswithin boxes indicate that the component hasbeen
decomposed to sub-components.
 Arrowsmean that data and or control signals arepassedfrom
component to component in the direction of the arrows.

 Software architecture is important becauseit affects the
performance, robustness, three advantages of explicitlydesigning
and documenting
 Software architecture: distributability, and maintainability ofa
system.
1. Stakeholder communication
2. System analysis
3. Large-scale reuse

 Becauseof the close relationship between non-functional
requirements and software architecture, theparticular architectural
style and structure that you choose for asystem should depend on
the non-functional systemrequirements:
1. Performance
 Ifperformance is acritical requirement, the architecture should be
designed to localize critical operations within asmall number of
components, with these components all deployed on the same
computer rather than distributed acrossthenetwork.
2. Security
 If security is acritical requirement, alayered structure for the
architecture should be used, with the most critical assets protected in
the innermost layers, with ahigh level of security validation applied
to theselayers.

3. Safety
 If safety is acritical requirement, the architecture should be designed
sothat safety-related operations are all located in either asingle
component or in asmall number ofcomponents.
 Thisreduces the costs and problems of safety validation and makesit
possible to provide related protection systemsthat can safely shut
down the system in the event of failure.
4. Availability
 If availability is acritical requirement, the architecture should be
designed to include redundant components sothat itis possible to
replace and update components without stopping thesystem.

5. Maintainability
 If maintainability is acritical requirement, the system architecture
should be designed using fine-grain, self-contained components that
may readily be changed. Producers of data should be separatedfrom
consumers and shared data structures should beavoided.

Figure2 : 4+1 ArchitecturalView Model

 Theviews that he suggestsare:
1. ALogicalView, which shows the key abstractions in the system as
objects or object classes.It should be possible to relate the system
requirements to entities in this logical view.
2. AProcessView, which shows how, at run-time, the system is
composed of interacting processes. Thisview is useful formaking
judgments about nonfunctional system characteristics such as
performance and availability.
3. ADevelopment View, which shows how the software is
decomposed for development, that is, it shows the breakdown of
the software into components that are implemented by asingle
developer or development team. Thisview is useful for software
managers and programmers.

4. APhysicalView, which shows the system hardware and how
software components are distributed across the processors in the
system. Thisview is useful for systemsengineers planning asystem
deployment.
 Conceptualview is an abstract view of the system that can be the
basisfor decomposing high-level requirements into more detailed
specifications, help engineers make decisions about components that
canbe reused.
 In practice, conceptual views are almost always developed during the
design process and are used to support architectural decisionmaking.
 Theyare away of communicating the essenceof asystem todifferent
stakeholders.

 Theidea of patterns asaway of presenting, sharing, andreusing
knowledge about softwaresystems.
 Architectural patterns were proposed in the 1990s under the name
‗architectural styles‘.
 Next point describes the well-known Model-View-Controllerpattern.
 Thispattern is the basisof interaction management inmany web-
based systems.
 Thestylized pattern description includes the pattern name, abrief
description (with an associated graphical model), and an exampleof
the type of system where the pattern is used.

 Pattern Name : MVC
 Description: Separatespresentation and interaction from thesystem
data. Thesystem is structured into three logical components that
interact with eachother.
 TheModel component manages the systemdata andassociated
operations on that data.
 TheView component defines and manages how the data ispresented
to theuser.
 TheController component manages user interaction (e.g., key
presses, mouse clicks, etc.) and passesthese interactions to theView
and the Model.
 Example: Figure 6.4 shows the architecture of aweb-based
application system organized using the MVCpattern.

 When used: Usedwhen there are multiple waysto view andinteract
with data.Also used when the future requirements for interaction
and presentation of data areunknown.
 Advantages: Allows the data to change independently of its
representation and vice versa. Supports presentation of thesame
data in different wayswith changes made in one representation
shown in all ofthem.
 Disadvantages: Caninvolve additional code and code complexity
when the data model and interactions aresimple.

 Y
oushould also include information about when the patternshould
be used and its advantages anddisadvantages.
 Graphical models of the architecture associated with the MVC
pattern are shown in Figures 6.3 and6.4.
 Thesepresent the architecture from different views—Figure 6.3 is a
conceptual view and Figure 6.4 shows apossible run-time
architecture when this pattern is used for interaction management in
aweb-based system.

Figure6.3 : Theorganizationof the MVC

Figure6.4 : Webapplicationarchitecture usingthe MVC pattern

1. Layered Architecture
 Thenotions of separation and independence are fundamentalto
architectural design becausethey allow changes to belocalized.
 TheMVCpattern separates elements of asystem, allowing them to
change independently.
 For example, adding anew view or changing an existing view canbe
done without any changes to the underlying data in the model.
 Thelayered architecture pattern is another way ofachieving
separation and independence.
 Thispattern is shown asbelow :-

 Name of Pattern : LayeredArchitecture Pattern
 Description: Organizesthe system into layers with related
functionality associated with eachlayer.
 Alayer provides services to the layer above it sothe lowest-level
layers represent core services that are likely tobe used throughout
the system. SeeFigure 6.6.
 Example: Alayered model of asystem for sharing copyright
documents held in different libraries, asshown in Figure6.7.
 When Used: Usedwhen building new facilities on top of existing
systems;when the development is spread acrossseveral teamswith
each team responsibility for alayer of functionality; when there is a
requirement for multi-levelsecurity.

 Advantages: Allows replacement of entire layers solong asthe
interface ismaintained.
 Redundant facilities (e.g., authentication) can be provided ineach
layer to increase the dependability of the system.
 Disadvantages: In practice, providing aclean separation between
layers is often difficult and ahigh-level layer may have to interact
directly with lower-level layers rather than through the layer
immediately below it.
 Performance can be aproblem because of multiple levelsof
interpretation of aservice request asit is processed ateach layer.

 Thislayered approach supports the incremental developmentof
systems.
 Asalayer is developed, some of the services provided by thatlayer
may be made available to users.
 Thearchitecture is also changeable and portable.
 Solong asits interface is unchanged, alayer can be replacedby
another, equivalent layer.
 When layer interfaces change or new facilities are added toalayer,
only the adjacent layer isaffected.
 Figure6.6 is an example of alayered architecture with fourlayers.

 Thelowest layer includes system support software—typically
database and operating systemsupport.
 The next layer is the application layer that includes the components
concerned with the application functionality and utility components
that are used by other applicationcomponents.
 Thethird layer is concerned with user interface management and
providing user authentication and authorization, with the top layer
providing user interfacefacilities.
 the number of layers is arbitrary. Any of the layers in Figure 6.6 could
be split into two or more layers.

Figure6.6 :Agenericlayeredarchitecture

 Figure 6.7 is an example ofhow this layered architecture pattern can
be applied to alibrary systemcalled LIBSYS,which allows controlled
electronic accessto copyright material from agroup of university
libraries.
 Thishasafive-layer architecture, with the bottom layerbeing the
individual databases in eachlibrary.

Figure6.7 : Thearchitecture of the LIBSYSsystem

2. RepositoryArchitecture
 Thelayered architecture and MVCpatterns are examples of patterns
where the view presented is the conceptual organization ofasystem.
 TheRepository pattern describes how aset of interacting
components canshare data.
 Themajority of systemsthat uselarge amounts ofdata are organized
around ashared database or repository.
 Thismodel istherefore suitedto applicationsin whichdata is
generatedbyonecomponentandusedby another.
 Examplesof this type of system include command and control
systems, management information systems, CADsystems, and
interactive development environments forsoftware.

 Name of Pattern : TheRepository Pattern
 Description: All data in asystem is managed in acentral repository
that is accessible to all system components. Components do not
interact directly, only through therepository.
 Example: Figure 6.9 is an example of an IDEwhere the components
usearepository of system design information. Eachsoftware tool
generates information which is then available for useby othertools.
 When Used: Y
oushould usethis pattern when you have asystem in
which large volumes of information are generated that hasto be
stored for alongtime.
 Y
oumay also useit in data-driven systemswhere the inclusionof
data in the repository triggers an action or tool.

 Advantages: Components canbe independent—they do not need to
know of the existence of other components.
 Changesmade by one component can be propagated to all
components.
 All data can be managed consistently (e.g., backups done at thesame
time) asit is all inone place.
 Disadvantages: Therepository is asingle point of failure soproblems
in the repository affect the whole system.
 May be inefficiencies in organizing all communication throughthe
repository.
 Distributing the repository across several computers may bedifficult.

 Figure6.9 is an illustration of asituation in which arepositorymight
be used.
 Thisdiagram shows an IDEthat includes different tools to support
model-driven development.
 Therepository in this casemight be aversion-controlled environment
that keeps track of changes to software and allows rollback to earlier
versions.
 Organizing tools around arepository is an efficient way to sharelarge
amounts of data.
 There is no need to transmit data explicitly from one component to
another.
 In the example shown in Figure6.9, the repository is passiveand
control is the responsibility of the components using the repository.

Figure6.9 :Arepositoryarchitecture for anIDE

3. Client- ServerArchitecture
 The repository pattern is concerned with the static structure of a
system and does not show its run-timeorganization.
 Client server architecture is used for run-time organizationfor
distributed systems.
 Asystem that follows the client–server pattern is organized asasetof
services and associated servers, and clients that accessand usethe
services.
 Themajor components of this modelare:

1. Aset of servers that offer services to other components.
 Examplesof servers include print servers that offer printing services,
file servers that offer file management services, and acompileserver,
which offers programming language compilationservices.
2. Aset of clients that call on the services offered by servers. There will
normally be several instances of aclient program executing
concurrently on different computers.
3. Anetwork that allows the clients to accesstheseservices. Most
client–server systemsare implemented asdistributed systems,
connected using Internet protocols.

 Name of Pattern : The Client–server
 Description: In aclient–server architecture, the functionality of the
system is organized into services, with each service delivered from a
separate server. Clients are users of these services and accessservers
to make useof them.
 Example: Figure 6.11 is an example of afilm and video/DVD library
organized asaclient–server system.
 When Used: Usedwhen data in ashared database hasto be
accessedfrom arange of locations. Becauseservers canbe
replicated, may also be used when the load on asystem isvariable.

 Advantages: Theprincipal advantage of this model is thatservers
canbe distributed acrossanetwork.
 General functionality (e.g., aprinting service) can be available toall
clients and does not need tobe implemented by all services.
 Disadvantages: Eachservice is asingle point of failure so susceptible
todenial of service attacks or server failure.
 Performance may be unpredictable becauseit depends onthe
network aswell asthe system.
 May be management problems if servers are owned bydifferent
organizations.

Figure6.11 :Aclient—serverarchitecture for a filmlibrary

4. PipeandFilter Architecture
 Thisis amodel of the run-time organization ofasystem where
functional transformations process their inputs and produceoutputs.
 Data flows from one to another and is transformed asit moves
through the sequence.
 Eachprocessing step is implemented asatransform. Input data flows
through these transforms until converted tooutput.
 Thetransformations may execute sequentially or in parallel. Thedata
canbe processed by each transform item by item or inasingle batch.

 Name of Pattern : ThePipeand filter
 Description: Theprocessing of the data in asystem is organizedso
that each processing component (filter) is discrete and carries out
one type of data transformation. Thedata flows (asinapipe) from
one component to another forprocessing.
 Example: Figure 6.13 is an example of apipe and filter systemused
for processinginvoices.
 When Used: Commonly used in data processing applications (both
batch- and transaction-based) where inputs are processed in
separate stagesto generate relatedoutputs.

 Advantages: Easyto understand and supports transformation reuse.
 Workflow style matches the structure ofmany business processes.
 Evolution by adding transformations isstraightforward.
 Canbe implemented aseither asequential or concurrent system.
 Disadvantages: Theformat for data transfer hasto be agreedupon
between communicating transformations.
 Eachtransformation must parse its input and unparse its outputto
the agreedform.
 Thisincreases systemoverhead and may mean that it is impossibleto
reuse functional transformations that useincompatible data
structures.

Figure6.13 :Anexampleof the pipeandfilter architecture

 Theapplication architecture may be re-implemented when
developing new systemsbut, for many business systems,application
reuse is possible without reimplementation.
 Asasoftware designer, you canusemodels of application
architectures in anumber ofways:
1. Asa starting point for the architecturaldesignprocess:-
 If you are unfamiliar with the type of application that you are
developing, you canbaseyour initial design on agenericapplication
architecture.
2. Asa designchecklist:-
 If you have developed an architectural design for anapplication
system, you can compare this with the generic application
architecture.
 Y
oucan check that your design is consistent with thegeneric
architecture.

3. Asa way of organizingthe work of the development team:-
 Theapplication architectures identify stable structural features ofthe
system architectures and in many cases,it is possible to develop
these in parallel.
 Y
oucan assign work to group members to implementdifferent
components within thearchitecture.
4. Asa meansof assessingcomponentsfor reuse :-
 If you have components you might be able toreuse, you can compare
these with the generic structures to seewhether there are
comparable components in the applicationarchitecture.

5. Asa vocabulary for talking about typesof applications:-
 If you are discussing aspecific application or trying to compare
applications of the sametypes, then you canuse the concepts
identified in the generic architecture to talk about the applications.

1. TransactionProcessingSystems
 Transaction processing (TP)systemsare designed to process user
requests for information from adatabase, or requests to update a
database.
 Technically, adatabase transaction is sequence of operations that is
treated asasingle unit (an atomicunit).
 All of the operations in atransaction have to be completed before the
database changes are made permanent.
 This ensures that failure of operations within the transaction does
not lead toinconsistencies in the database.

 From auser perspective, atransaction is any coherent sequence of
operations that satisfies agoal, such as‗find the times of flights from
London to Paris‘.
 If the user transaction does not require the database to be changed
then it may not be necessary to package this asatechnical database
transaction.
 An example of atransaction is acustomer request towithdraw
money from abank account using anATM.
 Thisinvolves getting details of the customer‘s account, checkingthe
balance, modifying the balance by the amount withdrawn, and
sending commands to theATMto deliver the cash.
 Until all of these steps have been completed, the transaction is
incomplete and the customer accounts database is notchanged.

 Transaction processing systemsare usually interactive systemsin
which users make asynchronous requests for service.
 Figure6.14 illustrates the conceptual architectural structure ofTP
applications.
 First auser makesarequest to the system through an I/Oprocessing
component.
 Therequest is processed by some application specific logic.
 Atransaction is created and passedto atransaction manager,which
is usually embedded in the database managementsystem.
 After the transaction manager hasensured that the transaction is
properly completed, it signals to the application that processing has
finished.

Figure6.14 :TheDatabasestructure of transaction processingapplications

 Transaction processing systemsmay be organized asa‗pipe and filter‘
architecture with system components responsible for input,
processing, and output.
 For example, consider abanking system that allows customersto
query their accounts and withdraw cashfromanATM.
 The system is composed of two cooperating software components—
the ATM software and the account processing software in the bank‘s
database server.
 Theinput and output components are implemented assoftwarein
the ATMand the processing component is part of the bank‘s
database server.
 Figure6.15 shows the architecture of this system, illustratingthe
functions of the input, process, and outputcomponents.

Figure6.15 :Thesoftwarearchitecture of anATM system

2. Informationsystems
 All systemsthat involve interaction withashared database canbe
considered to be transaction-based informationsystems.
 An information systemallows controlled accessto alarge baseof
information, suchasalibrary catalog, aflight timetable, or the
records of patients in ahospital.
 Increasingly, information systemsare web-based systemsthat are
accessedthrough aweb browser.

 Figure 6.16 avery general model of an informationsystem.
 Thesystem is modeled using alayered approach where the top layer
supports the user interface and the bottom layer is the system
database.
 Theuser communications layer handles all input and output fromthe
user interface, and the information retrieval layer includes
application-specific logic for accessing and updating thedatabase.

Figure6.16 : Layeredinformation system architecture

 Asan example of an instantiation of this layered model,Figure6.17
shows the architecture of theMHC-PMS.
 Recallthat this system maintains and manages details of patientswho
are consulting specialist doctors about mental healthproblems.

Haveadded detail to each layer in the model by identifying the
components that support user communications andinformation
retrieval andaccess:
1. Thetop layer is responsible for implementing theuser interface. In
this case,the UI hasbeen implemented using aweb browser.

2. Thesecond layer provides the user interface functionality thatis
delivered through the webbrowser.
 It includes components to allow users to log in to the system and
checking components that ensure that theoperations they useare
allowed by their role.
 This layer includes form and menu management components that
present information to users, and data validation components that
check information consistency.
3. Thethird layer implements the functionality of the systemand
provides components that implement system security, patient
information creation and updating, import and export of patient
data from other databases, and report generators that create
management reports.
4. Finally, the lowest layer, which is built using acommercialdatabase
management system, provides transaction management and
persistent data storage.

3. Languageprocessingsystems
 Languageprocessing systemstranslate anatural or artificial language
into another representation of that language and, for programming
languages, may also execute the resultingcode.
 In software engineering, compilers translate anartificial
programming language into machinecode.
 Other language-processing systemsmay translate an XMLdata
description into commands to query adatabase or to an alternative
XMLrepresentation.
 Natural language processing systemsmay translate onenatural
language to another e.g., French toNorwegian.

 Apossible architecture for alanguage processing system for a
programming language is illustrated in Figure6.18.
 Thesource language instructions define the program to beexecuted
and atranslator converts these into instructions for an abstract
machine.
 Theseinstructions are then interpreted by another componentthat
fetches the instructions for execution and executes them using (if
necessary) data from theenvironment.
 The output of the process is the result of interpreting the instructions
on the inputdata.

Figure6.18 : Thearchitecture of alanguageprocessing system

 Of course, for many compilers, the interpreter is ahardware unitthat
processesmachine instructions and the abstract machine is areal
processor.
 However, for dynamically typed languages, suchasPython, the
interpreter may be asoftware component.
 Programming language compilers that are part of amore general
programming environment have ageneric architecture (Figure6.19)
that includes the followingcomponents:
1. Alexicalanalyzer, which takes input language tokens and converts
them to an internalform.
2. Asymboltable, which holds information about the namesofentities
(variables, classnames, object names, etc.) used in the text that is
being translated.

3. Asyntaxanalyzer, which checks the syntax of the language being
translated. It usesadefined grammar ofthe language and builds a
syntax tree.
4. Asyntaxtree, which is an internal structure representing the
program being compiled.
5. Asemanticanalyzerthat usesinformation from the syntax treeand
the symbol table to check the semantic correctness of the input
language text.
6. Acodegenerator that ‗walks‘ the syntax tree and generatesabstract
machine code.

 Thispipe and filter model of language compilation is effective in
batch environments where programs are compiled and executed
without user interaction; for example, in the translation of one XML
document to another.
 It is less effective when acompiler is integrated with other language
processing tools suchasastructured editing system, an interactive
debugger or aprogram prettyprinter.
 In this situation, changes from one component need to be reflected
immediately in othercomponents.
 It is better, therefore, to organize the system around arepository, as
shown in Figure6.20.

Figure6.20 :Arepositoryarchitecturefor alanguageprocessingsystem

 Thisfigure illustrates how alanguage processing system canbe part
of an integrated set of programming support tools.
 In this example, the symbol table and syntax tree act asacentral
information repository. Toolsor tool fragments communicatethrough
it.
 Other information that is sometimes embedded in tools,suchasthe
grammar definition and the definition of the output format for the
program, have been taken out of the tools and put into the
repository.
 Therefore, asyntax-directed editor cancheck that the syntax of a
program is correct asit is being typed and aprettyprinter cancreate
listings of the program in aformat that is easy to read.

What isa Component?

Acomponent is amodular building block for computersoftware.
 Acomponent is amodular, deployable, and replaceable part of a
system that encapsulates implementation & exposesaset of
interfaces.
 Components reside within asoftware architecture, they must
communicate and collaborate with other components & with entities
(e.g. other systems, devices, people) that exist outside the
boundaries of the software.

AnObjectOriented View
 Acomponent contains aset of collaboratingclasses.
 Eachclasswithin acomponent hasbeen fully elaborated to include
all attributes and operations that are relevant to its implementation.
 Aspart of design elaboration, all interfaces that enable theclassesto
communicate & collaborate with other design classesmust also be
defined.
 T
oaccomplish this, you begin with the requirements model &
elaborate, analysis classes(for components that relate to the
problem domain) & infrastructure classes(forcomponents that
provide support services for the problemdomain).
 T
oillustrate this process of design elaboration, consider softwareto
be built for asophisticated printshop.

 Theoverall intent of the software is to collect the customer's
requirements at the front counter, cost aprint job, & then passthe
job on to an automated productionfacility.
 During requirements engineering, an analysis classcalled PrintJob
was derived.
 Theattributes &operations defined during analysis are noted at the
top of Figure10.1.
 During architectural design, PrintJobis defined asacomponent
within the software architecture & is represented using shorthand
UMLnotation shown in middle right of the Figure 10.1.
 Note that PrintJobhas2 interfaces, computeJob,which provides job
costing capability, & initiateJob, which passesthe job along to the
production facility.

 Theseare represented using the ―lollipop‖ symbols shown to theleft
of the componentbox.
 Component level design begins at thispoint.
 Thedetails of the component PrintJobmust be elaborated toprovide
sufficient information to guideimplementation.
 Theoriginal analysis classis elaborated to flesh outall attributes &
operations required to implement the classasthe component
PrintJob.
 Referring to the lower right portion of Figure 10.1, the elaborated
design classPrintJobcontains more detailed attribute information as
well asan expanded description of operations required toimplement
the component.
 Theinterfaces computeJob& initiateJob imply communication &
collaboration with other components (notshown here).

 For example, the operation computePageCost() (part of the
computeJob interface) might collaborate with a PricingTable
component that contains job pricinginformation.
 ThecheckPriority() operation (part of the initiateJob interface)might
collaborate with aJobQueuecomponent to determine the types &
priorities of jobs currently awaitingproduction.
 Thiselaboration activity is applied to every component definedas
part of the architecturaldesign.
 Onceit is completed, further elaboration is applied toeach attribute,
operation, & interface.
 Thedata structures appropriate for each attribute must bespecified.

Figure10.1 : Elaboration of adesign component

TraditionalView
 In the context of traditional software engineering, a component is a
functional element of aprogram 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 &data to be passedto it.
 Atraditional component, also called aModule, resides within the
software architecture & serves one of 3 important roles :-
1. AControl Component that coordinates the invocation ofall other
problem domain components.
2. AProblem Domain component that implements acompleteor
partial function thatis required by the customer.
3. An Infrastructure component that is responsible for functionsthat
support the processing required in the problem domain.

 LikeOOcomponents, traditional software components are derived
from the analysismodel.
 AsFigure 10.2, Eachbox represents asoftware component.
 Note that the shaded boxes are equivalent in function to the
operations defined for the PrintJobclass.
 In this case,however, each operation is represented asaseparate
module that is invoked asshown in Figure 10.2. Other modulesare
used to control processing & are therefore control components.
 During component level design, each module in Figure 10.2is
elaborated.
 Themodule interface is defined explicitly.
 That is, each data or control object that flows across the interface is
represented.
 The data structures that are used internal to the module are defined.

Figure10.2 : Structure Chartfor a Traditional System

 T
oillustrate this process, consider the module ComputePageCost.
The intent of this module is to compute the printing cost per page
based on specifications provided by thecustomer.
 Data required to perform this function are :- numberof pagesin the
document,total numberof documentsto beproduced,one-or-two-
sideprinting, colorrequirements, & sizerequirements.
 Thesedata are passedto ComputePageCostvia the module‘s
interface.
 ComputePageCostusesthese data to determine apagecost that is
based on the interface.

Figure10.3 : Component-Leveldesignfor ComputePageCost

 Figure 10.3 represents the component-level design using amodified
UMLnotation.
 TheComputePageCostmodule accessesdata by invoking the module
getJobData,which allows all relevant data to be passed to the
component, & adatabase interface, accessCostDB,which enablesthe
module to accessadatabase that contains all printingcosts.
 Asdesign continues, the ComputePageCostmodule is elaborated to
provide algorithm detail & interface detail (Figure 10.3).
 Algorithm detail can be represented using the pseudocodetext
shown in figure or with aUMLactivitydiagram.
 Theinterfaces are represented asacollection of input & outputdata
objects or items.
 Designelaboration continues until sufficient detail is providedto
guide construction of thecomponent.

Process-RelatedView
 Thesoftware community hasemphasized the need to buildsystems
that make useof existing software components ordesign patterns.
 In essence,acatalog of proven design or code-level componentsis
made available to you asdesign workproceeds.
 Asthe software architecture is developed, you chose componentsor
design patterns from the catalog & usethem to populate the
architecture.
 Becausethese components have been created with reusability in
mind, acomplete description of their interface, the function(s) they
perform, & the communication & collaboration they require are all
available to you.

Designing ClassBased
Components

BasicDesignPrinciples
1. TheOpen-ClosedPrinciple (OCP)
 “A module *component+ should be open for extension but closedfor
modification”.
 Y
oushould specify the component in away 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.
 T
oaccomplish this, you create abstractions that serve asbuffer
between the functionality that is likely to be extended & the design
classitself.

 For example, assumethat assumethat the SafeHomesecuritymakes
useof aDetector classthat must check the status of each type of
security sensor.
 It is likely that astime passes,the number & types of security sensors
will grow.
 If internal processing logic is implemented asasequence of if-then-
else constructs, each addressing adifferent sensor type, the addition
of anew sensor type will require additional internal processing logic
(still another if-then-else).
 Thisis aviolation of OCP
.
 Oneway to accomplish OCPfor the Detector classis asFigure10.4.
 Thesensorinterface presents aconsistent view of sensorsto the
detector component.
 If anew type of sensor is added no change is required for the
Detector class (component). TheOCPis Preserved.

2. TheLiskovSubstitutionPrinciple(LSP)
 “Subclassesshould be substitutable for their baseclasses”.
 Abaseclassshould continue to function properly if aclassderived
from the baseclassis passedto the componentinstead.
 LSPdemands that any classderived from abaseclassmust honor any
implied contract between the baseclass& the components that use
it.
 A―contract‖ is aprecondition that must be true before the
component usesabaseclass& apostcondition that should be true
after the component usesabaseclass.
 When you create derived classes, be sure they conform to the pre- &
postconditions.

3. DependencyInversionPrinciple (DIP)
 “Depend on abstractions. Donot depend onconcretions.”
 Abstractions are the place where adesign canbe extended without
great complication.
 Themore acomponent depends on other concrete components
(rather than on abstractions such asan interface), the more difficult it
will be to extend.

4. TheInterface SegregationPrinciple (ISP)
 “Many client-specific interfaces are better than one general purpose
interface”.
 There are many instances in which multiple client componentsuse
the operations provided by aserverclass.
 ISPsuggests that you should create aspecialized interface to serve
each major category of clients.
 Only those operations that are relevant toaparticular 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 specializedinterfaces.

 Asan example, consider the FloorPlan classthat is used for the
SafeHomesecurity & surveillancefunctions.
 For the security functions, FloorPlanis used only duringconfiguration
activities & usesthe operations placeDevice(), showDevice(),
groupDevice() & remoteDevice() to place, show, group, & remove
sensorsfrom the floorplan.
 TheSafeHomesurveillance function usesthe four operations for
security, but also requires special operations tomanage cameras :-
showFOV()& showDeviceID().
 Hence, the ISP

5. TheReleaseReuseEquivalencyPrinciple (REP)
 “The granule (small seed) of reuse is the granule ofrelease”.
 When classesor components are designed for reuse, there is an
implicit contract that is established between the developer of the
reusable entity & the people who will use it.
 The developer commits to establish a release control system that
supports & maintains older versions of the entity while the users
slowly upgrade to the most currentversion.
 Rather than addressing each classindividually, it is often advisableto
group reusable classesinto packagesthat canbe managed &
controlled asnewer versions evolve.

6. TheCommonClosurePrinciple (CCP)
 “Classesthat change together belongtogether”.
 Classesshould be packed cohesively, i.e. they should addressthe
samefunctional or behavioralarea.
 When some characteristic of that area must change, it is likely that
only those classeswithin the packagewillrequire modification.
 Thisleads to more effective change control &release management.

7. TheCommonReusePrinciple(CRP)
 “Classesthat aren’t reused together should not be groupedtogether”.
 When one or more classeswithin apackagechanges, therelease
number of the packagechanges.
 All other classesor packagesthat rely on the packagethat hasbeen
changed must now update to the most recent release of the package
& be tested to ensure that the new release operates without
incident.
 If classesare not grouped cohesively, it is possible that aclasswith no
relationship to other classeswithin apackage ischanged.

Component-LevelDesign Guidelines
 Components:- Naming conventions should be established for
components that are specified aspart of the architectural model &
then refined & elaborated aspart of the component-level model.
 Architectural component names should be drawn from theproblem
domain & should have meaning to all stakeholders who view the
architectural model.
 For example, the classname FloorPlanis meaningful to everyone
reading it regardless of technicalbackground.
 Interfaces :-
 Interface provide important informationabout communication &
collaboration.

 Dependencies& Inheritance:-
 For improved reliability, itis agood idea to model dependencies from
left to right & inheritance from bottom (derived classes) to top (base
classes).
 In addition, component interdependencies should be representedvia
interfaces, rather than by representation of acomponent-to-
component dependency.

Cohesion
 Cohesion implies that acomponent or classencapsulates only
attributes & operations that are closely related to one another & to
the classor componentitself.
 Different types of cohesion:-
 Functional :- It shows primarily by operations, this level of cohesion
occurs when a component performs a targeted computation & then
return aresult.
 Layer:- It shows by packages, components, & classes,this type of
cohesion occurs when ahigher layer accessesthe services of alower
layer, but lower layers do not accesshigherlayers.
 For example, the SafeHomesecurity function requirement tomale an
outgoing phone call if an alarm issensed.

 It might be possible to define aset oflayered packagesasshown in
Figure 10.5.
 Theshaded packagescontain infrastructure components.
 Accessis from the control panel packagedownward.
 Communicational :- All operations that accessthe samedataare
defined within oneclass.
 In general, suchclassesfocus solely on the data in question,accessing
& storingit.
 Classes& components that exhibit functional, layer, &
communicational cohesion are relatively easyto implement, test,&
maintain.
 Y
oushould strive to achieve these levels of cohesionwhenever
possible.

Coupling
 Coupling is aqualitative measure of the degree towhich classesare
connected to oneanother.
 Asclasses(& components) become more interdependent, coupling
increases.
 Objective in component-level design is to keep Coupling aslowas
possible.
 Different coupling categories:-
 Content Coupling :- Occurs when one component modifies data that
is internal to another component. This violates information hiding – a
basic design concept.
 CommonCoupling:- Occurswhen ano. of components all make use
of aglobal variable.

 ControlCoupling:- Occurswhen operation A() invokes operation B()
& passesacontrol flag to B.Thecontrol flag then ―directs‖ logical
flow within B.
 The problem with this form of coupling is that an unrelated change in
Bcan result in the necessity to change the meaning of the control flag
that Apasses.If this is overlooked, an error willresult.
 StampCoupling:- Occurswhen ClassBis declared asatype for an
argument of an operation of ClassA.BecauseClassBis now apart of
the definition of ClassA,modifying the system becomes more
complex.

Conducting Component
Level Design

 Following are the component-Level Designsteps for anobject
oriented systems:-
1. Identify thosedesignsclassesthat correspondsto the problem
domain.
 Using the requirements &architectural model, each analysis class&
architectural component should beelaborated.
2. Identify all designclassesthat are correspondsto infrastructure
domain.
 Theseclassesare not described in the requirements model &are
often missing from the architecture model, but they must be
described at this point.

3. Elaborateall designclassesthat are not acquiredasreusable
components.
 Elaboration requires that all interfaces, attributes, & operations
necessary to implement the classbe described indetail.
3.a. Specifymessagedetailswhenclassesor componentscollaborate.
Therequirement model makesuseof acollaboration diagram toshow
how analysis classescollaborate with oneanother.
Ascomponent-level design proceeds, it is sometimes useful to showthe
details of these collaborations by specifying the structure of messages
that are passedbetween objects within asystem.
Figure 10.6 shows asimple collaboration diagram for the printing
system. 3 objects, ProductionJob,WorkOrder,& JobQueue,collaborate
to prepare aprint job for submission to the production stream.
Messagesare passedbetween objects asshown by the arrows in the
Figure 10.6.

Figure10.6 : Collaboration diagramwith messaging

b.Identify appropriateinterfacesfor each component.
c.Elaborate attributes & define data types& data structures
required to implementthem.
d.Describeprocessingflow within eachoperationin detail.
Thismay accomplished using aprogramming language-based pseudo
code or with aUMLactivitydiagram.
Eachsoftware component is elaborated through ano. of iterationsthat
apply the stepwise refinementconcept.
For example, the operation computePaperCost()can be expanded in
the following manner:-
computePaperCost(weight, size,color): numeric
Thisindicates that computePapercost()requires the attributes weight,
size,& colorasinput & returns avalue that is numeric (actuallyadollar
value) asoutput.

Figure 10.8 : UMLactivity diagram for computePaperCost()

4. Describepersistentdata sources(databases& files) & identify the
classesrequired to managethem.
 In most cases,these persistent data stores are initially specifiedas
part of architecturaldesign.
 However, asdesign elaboration proceeds, it is often useful toprovide
additional detail about the structure & organization of these
persistent data sources.
5. Develop& elaborate behavioral representationsfor aclassor
component.
 UMLstate diagrams were used aspart of the requirements modelto
represent the externally observable behavior of the system.
 During component-level design, it is sometimes necessary tomodel
the behavior of adesignclass.

6. Elaboratedeployment diagramsto provideadditional
implementation detail.
 Deployment diagrams are used aspart of architectural design &are
represented in descriptorform.
 Deployment diagram canbe elaborated torepresent the location of
key packagesof components.
 However, components generally are not represented individually
within acomponent diagram.
7. Refactorevery component-level designrepresentation & always
consideralternatives.

Figure15.1 : TheUserInterface Design Process

 Thedesign process for user interfaces is iterative and canbe
represented using aspiral model Referring to Figure 15.1, theuser
interface design process encompasses four distinct framework
activities [MAN97]:
1. User,task, and environment analysis andmodeling
2. Interface design
3. Interface construction
4. Interface validation
1. Theinitial analysis activity focuses on the profile of the users who
will interact with the system. Skill level, business understanding, and
general receptiveness to the new system are recorded;and different
user categories are defined.

Theinformation gathered aspart of the analysis activityis used to
create an analysis model for theinterface.
2. The goal of interface design is to define aset of interface objects and
actions (and their screen representations) that enable auser to
perform all defined tasks in amanner thatmeets every usability goal
defined for thesystem.
3. TheInterface Construction (implementation activity) normally
begins withthe creation of aprototype that enables usagescenarios
to be evaluated. Asthe iterative design process continues, auser
interface tool kit may be used to complete the construction of the
interface.

4. Validation focuses on (1) the ability of the interface to implement
every user task correctly, to accommodate all task variations, and to
achieve all general user requirements; (2) the degree to which the
interface is easyto useand easyto learn; and (3) the users‘
acceptance of the interface asauseful tool in their work.

Typesof User Interface
 It means how user can communicate withcomputer systems.
 Twofundamental approaches are used to interface withthe
approaches are used to interface withcomputer system.
 Usecan communicate with computer using different commands
provided by the system.
 In another approach user interact by using user friendly graphical
user interface. Graphical user interface provides the menu & icon
based facility which can be used using keyboard & mouse.

1. CommandInterpreter
 In Command Interpreter, user communicates with computersystem
with the help ofcommands.
 In Unix/Linux system the command interpreter is known asShell.
 Shell is nothing but interface between user &OS.
 All the shells give similar facility with only minor changes.
 Selecting the particular shell totallydepends on user‘s requirement.
 CIjust accept the commands, call the corresponding program&
execute it.
 When we type the ‗cd‘ command, OSsearch the program for the‗cd‘
command & get itby executed.
 Many commands are provided byOS.
 Thekind of command is depends upon theOS.

 Thecommands are interpreted in different manner.
 In the first approach, the command interpreter itself contains the
code for the command.
 Whenever we type any command it will execute directly. Thesizeof
command interpreter depends upon the number of command
supported by the command supported by the commandinterpreter.
 In the second approach, separate program is created for each &every
command supported by the system.
 Whenever we need to execute any command, OSsearch theprogram
for it, load it into memory & get it executed.
 Theprogram for commands is stored oncertain

2. GraphicalUserInterface (GUI)
 Instead of directly entering commands throughacommand-line
interface, aGUIallows amouse-based, window & menu based
system asan interface.
 GUIgives the desktop environment where mouse & keyboard canbe
used.
 Mouse can be moved to certain location & when we click on come
location, OScalls the correspondingprogram.

Characteristicsof GoodUser Interface
1. Clarity
2. Concision
3. Familiarity
4. Responsiveness
5. Consistency
6. Aesthetics
7. Efficiency
8. Attractive
9. Forgiveness
Benefitsof GoodUser Interface
 Higher Revenue.
 Increased user efficiency & satisfaction.
 Reduced development costs.
 Reduced support costs.

TheGoldenRules
 Theo Mandel [MAN97] coins three ―goldenrules‖:
1. Placethe user in control.
2. Reducethe user‘s memoryload.
3. Make the interfaceconsistent.
 Thesegolden rules actually form the basisfor aset ofuser interface
design principles that guide this important softwaredesign activity.

1. Placethe Userin Control
 Number of design principles that allow the user to maintain control:
1. Define interaction modesin a waythat doesnot forcea userinto
unnecessaryor undesiredactions 
 An interaction mode is the current state of the interface. For
example, if spell check is selected in aword-processor menu,the
software moves to aspell checkingmode.
 There is no reason to force the user to remain in spell checking mode
if the user desires to make asmall text edit along the way.
 The user should be able to enter and exit the mode with little or no
effort.

2. Providefor flexible interaction 
 Becausedifferent users have different interaction preferences,
choices should be provided. For example, software might allow auser
to interact via keyboard commands, mouse movement, adigitizer
pen, or voice recognitioncommands.
 But every action is not amenable to every interaction mechanism.
 Consider, for example, the difficulty of using keyboard command (or
voice input) to draw acomplexshape.
3. Allow userinteraction to beinterruptible andundoable 
 Evenwhen involved in asequence of actions, the user should beable
to interrupt the sequence to do something else (without losing the
work that had beendone).
 Theuser should also be able to ―undo‖ anyaction.

4. Streamline interaction asskilllevelsadvanceandallow the
interaction to becustomized
 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.
5. Hidetechnicalinternalsfrom the casualuser 
 The user interface should move the user into the virtual world of the
application.
 Theuser should not be aware of the operating system, file
management functions, or other arcane computingtechnology.
 In essence,the interface should never require that the user interact
at alevel that is ―inside‖ the machine (e.g., auser should never be
required to type operating system commands from within application
software).

6. Designfor direct interaction with objectsthat appear onthe screen

 Theuser feels asenseof control when able to manipulate theobjects
that are necessary to perform atask in amanner similar to what
would occur if the objectwere aphysical thing.
 For example, an application interface that allows auser to―stretch‖
an object (scale it in size) is an implementation of direct
manipulation.

2. Reducethe User’sMemory
Load
 Themore auser hasto remember, the more error-prone willbe the
interaction with thesystem.
 It is for this reason that awell-designed user interface does not tax
the user‘smemory.
 Whenever possible, the system should ―remember‖ pertinent
information and assist the user withan interaction scenario that
assistsrecall.
 Mandel [MAN97] defines design principles that enable an interfaceto
reduce the user‘s memoryload:

1. Reducedemandonshort-term memory 
 When users are involved in complex tasks, the demand onshort-term
memory can be significant.
 Theinterface should be designed to reduce the requirementto
remember past actions andresults.
 Thiscanbe accomplished by providing visual cuesthat enable auser
to recognize past actions, rather than having to recall them.
2. Establishmeaningfuldefaults 
 Theinitial set of defaults should make sensefor theaverage user, but
auser should be able to specify individualpreferences.
 However, a―reset‖ option should be available, enablingthe
redefinition of original defaultvalues.

3. Define shortcutsthat are intuitive 
 When mnemonics are used to accomplish asystem function (e.g.,alt-
Pto invoke the print function), the mnemonic should be tied to the
action in away that is easyto remember (e.g., first letter of the task
to beinvoked).
4. Thevisuallayout of the interface shouldbebasedona real world
metaphor 
 For example, abill payment system should useacheck book and
check register metaphor to guide the user through the bill paying
process.
 Thisenables the user to rely on well-understood visual cues,rather
than memorizing an arcane interactionsequence.

5. Discloseinformation in a progressivefashion 
 Information about atask, an object, or some behavior shouldbe
presented first at ahigh level ofabstraction.
 More detail should be presented after the user indicates interest with
amouse pick.
 An example, common to many word-processing applications, isthe
underlining function.
 The function itself is one of anumber of functions under atext style
menu. However, every underlining capability is notlisted.
 Theuser must pick underlining, then all underlining options (e.g.,
single underline, double underline, dashed underline) arepresented.

3. Make the InterfaceConsistent
 Mandel [MAN97] defines aset of design principles that helpmake
the interfaceconsistent:
1. Allow the userto put the current taskinto ameaningfulcontext 
 Many interfaces implement complex layers of interactionswith
dozens of screenimages.
 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 hascome
from and what alternatives exist for atransition to anew task.
2. Maintain consistencyacrossafamily of applications 
 Aset of applications (or products) should all implement the same
design rules sothat consistency is maintained for allinteraction.

3. If pastinteractive modelshavecreated userexpectations,donot
makechangesunlessthere isa compellingreasonto doso
 Onceaparticular interactive sequence hasbecome ade facto
standard (e.g., the use of alt-S to saveafile), the user expects this in
every application heencounters.
 Achange (e.g., using alt-S to invoke scaling) will causeconfusion.

1. UserAnalysis
 Following information is used to accomplish thisuser analysis :-
1. UserInterviews:- Themost direct approach, members of the
software team meet with end users to better understand their
needs, motivations, work culture.
 Thiscanbe accomplished with one-on-one meetings or throughfocus
groups.
2. SalesInput :- Salespeople meet with users on aregular basis& can
gather information that will help the software team to categorize
users & better understand theirrequirements.
3. Marketing Input :-
4. SupportInput :- Support staff talks with users on adaily basis.They
are the most likely source of information on what works & what
doesn‘t what users like & what they dislike.

2. TaskAnalysis&Modeling
 The goal of task analysis is to answer the following questions :-
 What work will the user perform in specific circumstances ?
 What tasks & subtasks will be performed asthe user does the work ?
 What specific problem domain objects will the user manipulate as
work is performed ?
 T
oanswer these questions, you must applied certain techniques to
the userinterfaces.
1. UseCases :-
 Theusecaseis developed to show how an end user performssome
specific work-related task.
 Usecaseis written in an informal style (a simple paragraph) inthe
First-person.

 For example,Assumethat asmall software company wants to builda
computer aided design system explicitly for interiordesigners.
 T
oget abetter understanding of how they do their work, actual
interior designers are askedto describe aspecific designfunction.
 When asked: ―How do you decide where to put furniture in aroom ?‖
an interiordesigner writes the following informal usecase:
 accents –lamps, rugs, paintings, plants, smaller pieces, &my notes on
any desires my customers hasfor placement.
 I then draw each item from my lists using atemplate that is scaled to
the floor plan.
 I label each item I draw &usepencil becauseI always move things.
 I consider anumber of alternatives placements & decide on the one I
like best.
 Then, I draw arendering (a 3-D picture) of the room to give my
customer afeel for what it will look like.

 Thisusecaseprovides abasic description of one important worktask
for computer-aided designsystem.
 From it, you can extract tasks, objects, & the overall flow of the
interaction.
2. T
askElaboration:-
 T
askanalysis canbe applied in 2 ways.
 An interactive, computer based system is often used to replacea
manual or semi manualactivity.
 T
ounderstand the tasks that must be performed toaccomplish the
goal of the activity, you must understand the tasks that people
currently perform.
 Alternatively, you canstudy an existing specification for acomputer
based solution & derive aset of user tasks that will accommodate the
user model, the design model &system perception.

 For example, using information contained in usecase,furniture
layout canbe refined into following tasks:-
1. Draw afloor plan based on roomdimensions.
2. Placewindows & doors at appropriatelocations.
3. (a) Usefurniture templates to draw scaled furniture outlines on the
floor plan. (b) Useaccents template to draw scaled accents on the
floor plan.
4. Move furniture outlines & accent outlines to get the best placement.
5. Label all furniture & accentoutlines.
6. Draw dimensions to show location,&
7. Draw perspective-rendering view for thecustomer.
 Asimilar approach could be used for each of the other major tasks.

 Following are the interface designsteps:-
1. Using information developed during interface analysis, define
interface objects & actions(operations).
2. Define events (user actions) that will cause the state of the user
interface to change.
3. Depict each interface state asit will actually look to the end user.
4. Indicate how the user interprets the state of the system from
information provided through theinterface.
 Regardlessof sequence of tasks, youshould
(1) Always follow the GoldenRules.
(2) Model how the interface willbe implemented.
(3) Consider the environment (ex. Display technology, OS,development
tools that will beused).

ApplyingInterface Design Steps
 The definition of interface objects and the actions that are applied to
them.
 Description of auser scenario iswritten.
 Nouns (objects) and verbs (actions) are isolated to create alistof
objects and actions.
 Oncethe objects and actions have been defined andelaborated
iteratively, they are categorized by type. Target, source, and
application objects areidentified.
 Asource object (e.g., areport icon) is dragged and dropped onto a
target object (e.g., aprinter icon).

 Theimplication of this action is tocreate ahard-copy report.
 An application object represents application-specific data that isnot
directly manipulated aspart of screeninteraction.
 For example, amailing list is used to store namesforamailing.
 Thelist itself might be sorted, merged, orpurged (menu-based
actions) but itis not dragged and dropped via user interaction.
 When the designer is satisfied that all important objects and actions
have been defined (for one design iteration), screen layout is
performed.

 Likeother interface design activities, screen layout is an interactive
process in which graphical design and placement of icons,definition
of descriptive screen text, specification and titling for windows, and
definition of major and minor menu items is conducted.
 If areal world metaphor is appropriate for the application, it is
specified at this time and the layout is organized in amanner that
complements the metaphor.
Scenario :-
 Thehomeowner wishes to gain accessto the SafeHome system
installed in his house. Using software operating on aremote PC(e.g.,
anotebook computer carried by the homeowner while at work or
traveling), the homeowner determines the status of the alarm
system,arms or disarms the system,reconfigures security zones,and
views different rooms within the house via preinstalled video
cameras.

 T
oaccessSafeHomefrom aremote location, the homeowner
provides an identifier and apassword.
 Thesedefine levels of access(e.g., all users may not be ableto
reconfigure the system) and providesecurity.
 Oncevalidated, the user (with full accessprivileges) checksthestatus
of the system and changes status by arming ordisarming SafeHome.
 Theuser reconfigures the systemby displaying afloor plan of the
house, viewing each of the security sensors, displaying eachcurrently
configured zone, and modifying zonesasrequired.
 The user views the interior of the house via strategically placed video
cameras.
 Theuser canpan and zoom each camera to provide different viewsof
the interior.

Homeowner tasks :-
• accesses the SafeHomesystem
• enters an ID and passwordto allow remoteaccess
• checks systemstatus
• arms or disarms SafeHomesystem
• displays floor plan and sensorlocations
• displays zoneson floor plan
• changes zoneson floor plan
• displays videocameralocationson floor plan
• selects videocamerafor viewing
• views videoimages(4 frames per second)
• pans or zooms thevideocamera

 Objects (boldface) and actions (italics) are extracted from this list of
homeowner tasks.
 Themajority of objects noted are applicationobjects.
 However, video camera location (a source object) is dragged and
dropped onto video camera (a target object) tocreate avideo image
(a window with videodisplay).

DesignIssues
 Asthe design of auser interface evolves, four common designissues
almost always surface: systemresponsetime, userhelp facilities,
error information handling,andcommand labeling.
 SystemResponseTime :-
 System response time is the primary complaint for many interactive
applications.
 In general, system response time is measured from the point at which
the user performs some control action (e.g., hits the return key or
clicks amouse) until the software responds with desired output or
action.
 Systemresponse time hastwo important characteristics:lengthand
variability.
 If the length of system response is too long, user frustration and
stress is the inevitable result.

Design Engineering is a topic of software engineering of second year fourth semester

Design Engineering is a topic of software engineering of second year fourth semester

More Related Content

Design Engineering is a topic of software engineering of second year fourth semester