Vous êtes sur la page 1sur 5

Guidelines Based Software Engineering

Muthu Ramachandran
Faculty of Information and Technology
Leeds Metropolitan University
Headingley Campus
LEEDS LS6 3QS, UK
m.ramachandran@leedsmet.ac.uk

Abstract code, standard, regulation or


Software guidelines have been with us in many recommendation
forms within Software Engineering community
such as knowledge, experiences, domain In Software Design we use guidelines that help
expertise, laws, software design principles, us to identify a suitable design criterion when
rules, design heuristics, hypothesis, faced with design decisions. Software
experimental results, programming rules, best Engineering is a set of disciplined activities
practices, observations, skills, algorithms have that are based on well defines standards and
played major role in software development. procedures. Therefore software guidelines
This paper presents a new discipline known as summarises expert collection of design
Guidelines Based Software Engineering where judgements, rationales, and principles. This
the aim is to highlight the new principles as the can be used by students and experts alike.
main goal when developing software systems.
2. Guidelines Based Software
Keywords Software reuse, software Engineering
guidelines, software design knowledge, CBSE The very definition of Software Engineering
deals with best practice discipline to deal with
1. Introduction systematic approach to software development
Software Guidelines provide a precise set of and management. These best practices have
steps based on underlying software design been found throughout software development
principles which help us to follow any course life cycle. Starts from good program design by
of disciplined set of activities. The term Parnas (1979), Algorithms design by Dijkstra
guidelines are defined in the dictionary as (1982), concurrent programs by Hoare (1979)
follow: and they all provide good design guidelines. In
practice we are not sure of the process by
• A recommended approach, parameter, which to apply those principles. Therefore our
etc. for conducting an activity or task, work on software guidelines have started on
utilizing a product, etc. software components (Ramachandran and
• A statement of desired, good or best Sommerville 1992), extended to concurrency,
practice software process improvement, agile methods,
• Advice about how to design an and software product line based development
interface (aimed on good practice requirements
guidelines). Therefore we prefer to call
• A document used to communicate the
Guidelines Based Software Engineering which
recommended procedures, processes, aimed to collect best practices and experiences
or usage of a particular business as guidelines from many years of wealth of
practice knowledge in software engineering and apply
• A recommendation that leads or them wherever possible across all artefacts of
directs a course of action to achieve a software development. Guidelines provide
certain goal rationale for making a solution that has worked
• A written statement or outline of a well and successfully in previous applications,
policy, practice or conduct. environment, and in people. Figure 1 shows
Guidelines may propose options to the process view of guidelines based software
engineering.
enable a user to satisfy provisions of a
Software Formulate Assess the
Collect & effectiveness
artefacts & review
classify Apply of the Artefacts Improve and
Best and refine
guidelines guidelines re-design
Pratices

Improved
Programming- Application specific artefacts
specific knowledge knowledge

Figure 3.1 The process of Guidelines Based Software Engineering


Figure 1. The process of Guidelines Based Software Engineering

Guidelines
The process fallstates
intostartseveral categories domain
with gathering such as good topractice identifyguidelines
components on from your design
requirements
knowledge, engineering
classify domain, (Sommerville classify and bestSawyer 1995), RE methods-specific
abstracts as given below:
guidelines such onidentify
practice design, UML, artefacts
Use Case(components,
driven modelling, design (OO, generic design
principles), quality and SQA
patterns, frameworks), procedures
identify and best practices, software
and classify developmentfunctionality required
• Is component
(good
best program
practice design design and language-specific
guidelines on various guidelines), and good test process
on future implementations?
guidelines, and guidelines on
aspect of their design (for example how well software process improvement. Figure 3.2 shows an
• How common is the component's
example of a classification
requirements have beenof represented
guidelines on as software
use components. function within the domain?
cases and how well use case have been used • Is there duplication of the
C B S E d e fin ition
effectively and their features, how well OCL
component's function within the
specifications have been used to document and
C B S E p roce ss, m e th od s, te ch n iq u e s
describe the model). In case if the artefacts are domain?
Crepresented
BSE in any programming language, • Is the component hardware-
C B S E d esign , m od e llin g, im p le m e n ta tion
Gthen
u id elinidentify
es and classify best design dependent?
constructs that can be used for expressing • Does the hardware remain unchanged
C B S E D om a in E n gin e e rin g, C a se s tu d ie s
various design factors such as reuse, between implementations?
flexibility, security, and so on. Guidelines fall • Can the hardware specifics be
D e ve lop m en t for C om p on en t re u se , C a se
into several categoriesstusuch d ie s as good practice removed to another component?
guidelines on requirements engineering • Is the design optimized enough for
(Sommerville and Sawyer O rga1995),
n isa tion RE
a l & methods-
m a n a ge ria l
the next implementation?
specific guidelines such on UML, Use Case
Cana n we
C om p on e n t te stin g, va lid a tion , ce rtifica tion , •se cu rity d parameterize a non-reusable
driven modelling, design SQA
(OO, generic design
principles), quality and SQA procedures and component so that it becomes
F ig u r e 3 .2 C la ssific a tion of B e st P r a c tic e C B S E g u id e lin e s reusable?
best practices, software development (good
program design and language-specific • Is the component reusable in many
guidelines), and good test process guidelines, implementations with only minor
and guidelines on software process
Best practice guidelines on components based software engineering (CBSE) changes? fall into a
number categories The
improvement. such first
as definitions,
step in process, building methods, techniques, • Ismodels, reusedesign,
through modification
implementation,
guidelines based domain engineering,
SE is toanddevise development a for component reuse, component
feasible?
security, component
classification testing, validation, certification,
system/mechanism for collating and QSA.
• Can a non-reusable component be
guidelines which the useful for finding an
Guideline
appropriate on CBSE Definition and Classification decomposed to yield reusable
guideline.
CBSE approach should provide a methodology and process to define, components?
develop, test,
and maintain software components
Best practice guidelines on components based and its use in product assembly. • How valid is component
software engineering (CBSE) fall into a decomposition for reuse?
number categories such as definitions, process,
methods, techniques, models, design, Example of a Process Guideline for
implementation, domain engineering, and Component Identification: One rule of thumb
development for component reuse, component can be use here is to identify a group of related
security, component testing, validation, object classes to make up a self-independent
certification, and QSA. Identifying software component. UML view of component
components from your application models is a identification process is depicted in the
human intensive activity. This comes from following diagram (Figure 2). UML process
domain expertise. However, Pressman (2000) starts with identifying use cases, class
has identified a few self-assessment questions modeling, dynamic modeling (state transition
and message sequence models), collaboration
models (grouping related classes), packaging, where components and packages will be
components, and deployment/ implementation placed in the expected processors.
models (processors and network architectures)

Assign a
business value
for each
identified
component
Identify
Identify
Identify object classes
Collabora
requirements and
Identify tions
and Dynamic Compo
use cases diagrams
Requirements modelling nent
(Inception) (grouping
Analysis (state charts diagra
classes)
(Inception) and message ms
and
sequence
Packages
diagrams

Deployment
diagrams
(Implementation
model in terms
of processors
and networks

Figure 2. UML view of component identification


Figure 3.3 UML view of component identification

Implementation effort and Return on each identified components with domain


In a later(RoI):
Investment section This
we will
is discuss a commonality
an initial step in and variability
experts.analysis for component
CBSE identification
and it is intherefore
the context of a to
vital product family.
identify a
component which will have a longer life in Therefore, for each guideline, it is important to
your Implementation effort and
application domain ROI:
and This ishigh
hence an initial step in CBSE
present and it is therefore
a description, vital return on
illustration,
to identify a component which
returns on investment. Therefore it is will have a longer life
investment (RoI), and possibleand
in your application domain implementation
hence high returns on investment.
absolutely essential to have a business view to Therefore it is absolutely
effort essential
required alongto have
with a cost-benefit
business view to each identified components with domain experts.
analysis.
3. Guidelines,
Guideline on Component Observations,
Definition
Empirical Studies to Laws and
A software component is a self-contained entity which can be executed independently as well
Theories
as by combining with other parts. In addition, a component also has two distinct
Guidelines form principles
interfaces/services fromalso
(sometime observations,
called services in the guidelines, observations,
context of a modern approachand laws. Theories
to web
laws,based
and applications
theories. Observations, in software such as provider
and business applications) can alsointerfaces
help it predict
(a set ofnew facts from existing
interfaces
thatmean
terms, are to
offered to other
visually components
able to see changes to be
or connected) and requireobservations
guidelines, interfaces (a set andof laws. The
interfaces/services
results that are required
of an experiment/software toolsbyused
this by
component to work independently
diagram shown in and to provide
Figure 3 illustrates the
the needed
people, services successfully).
etc. However, Figure 3.4
these observations mayillustrates arelationships
component model
amongstfor aguidelines,
simple helpobservations,
desk
not be system. A modern
a repeatable event. Ahelp
lawdesk
cansystem is a complex software
be defined law, andsystem which
theory. is a web based
Guidelines also add human
and connects to all IT and corporate services. This system also follows IT service industry
as repeatable observations according to Endres perspective to observations, laws, and theories
standards and adapts to Information Technology Infrastructure Library (ITIL)
and recommendations
Rombach (2003).in For example,
a practical and aeffective
rainy manner.asOne it adds knowledge
such system can andbeexperiences.
seen at
season, symptoms of a widespread disease, etc.
www.sitehelpdesk.com. In this example this comments allows to log your IT help requests via
Theories
onlinecan help mobile
and using to explain and order our
devices.
reuses
predicts Confirmed by
Guideline

Observation

knowledge Is repeatable

Law

Theory

Experience Is non-
Explained by
repeatable

Figure 3 Guidelines, Observations, Laws, and Theories


We have used similar approach to domain- software engineering (CBSE) fall into a
specific modelling to generate reusable number categories such as definitions, process,
software components automatically for several methods, techniques, models, design,
application domains. An example of a CBSE implementation, domain engineering, and
guidelines classification system has been development for component reuse, component
shown in Figure 4 and their relevant guidelines security, component testing, validation,
have been adopted when designing software certification, and QSA.
components (Ramachandran 2008). Best
practice guidelines on components based
C B S E d e fin ition

C B S E p roce ss, m e th od s , te ch n iq u e s

CBSE C B S E d e sign , m od e llin g, im p le m e n ta tion


G u id elin es

C B S E D om a in E n gin e e rin g, C as e stu d ie s

D e ve lop m e n t for C om p on e n t re u se , C a se
s tu d ies

O rga n isa tion a l & m a n a ge ria l

C om p on e n t te stin g, va lid a tion , ce rtifica tion , se cu rity a n d


SQA
F ig u r e 4 C la s sific a tion of B e st P r a c tic e C B S E g u id e lin e s

Our earlier results have shown components for a simple help desk management system.
designed with guidelines seem to have The Table 1 shows an example of a list of
improved reuse and easy to re-design (more components and their reusability gain in
than 70% reusability gain has been achieved) percent.
Helpdesk system components Reuse gain
GUI component 1 50%
GUI component 2 40%
User records Management 70%
Job Status 55%
Test components 65%
Table 1 Component Reusability Gain
4. Conclusions
Guidelines based SE can create best practices testability, and customisability. These factors
as guidelines to be followed uniformly across achieve improving quality of the software
the development and business units. Our work systems and reducing software development
has shown increase in reusability, productivity, costs.
5. References
Brown, W. A and Wallnau, K. C (1998) The of the 2005 31st EUROMICRO
Current state of CBSE, Conference on Software Engineering and
September/October 1998. Advanced Applications (EUROMICRO-
Broy et al., M (1998) What characterizes a SEAA’05).
software component? Software – Concepts Ommering, Rob van et al (2000). The Koala
and Tools, 19(1):49–56, 1998. component model for consumer
Cheesman, J. and Daniels, J. (2000) UML electronics software, IEEE Computer,
Components, Addison Wesley. March 2000.
D’Souza and Wills (1999) Objects, Pressman (2005) SE, 6th Edition, McGraw
components and frameworks with UML, Hill.
Addison Wesley. Parnas, L (1979) Good program design, 1979,
Eddon, G and Eddon, H (1998) Inside Prentice-Hall
Distributed COM, Microsoft Press. Dijkstra, E. W (1979) Selected writings on
Endres, A and Rombach, D (2003) A computing: a personal perspective, ACM
Handbook of Software and Systems Classic Books Series, 1982
Engineering, Addison Wesley Sessions, R (1998) COM and DCOM, Wiley.
Heineman, G. T. and Councill, W. T (2001) Sommerville, I. (2005) Software Engineering,
Component-Based Software Engineering, 7th Edition, Addison Wesley.
Addison Wesley. Ramachandran, M and Sommerville (1992)
Hoare, T (1979) Concurrent programs, Software reuse assessment, First Intl.
Prentice-Hall workshop on software reuse, Germany
IEEE SW (1998) Special issue on Software Ramachandran, M (2008) Software
components, IEEE Software, September components: guidelines and applications,
1998. Nova Publishers, NY,
Jacobson, I et al (1997) Software Reuse: https://www.novapublishers.com/catalog/p
Architecture, Process and Organisation roduct_info.php?products_id=7577
for Business Success, Addison Wesley. Szyperski, C (1998) Component Software,
Lau, K-K and Wang, Z (2005) A Taxonomy of Addison Wesley.
Software Component Models, Proceedings