SOFTWARE

ENGINEERING
Case Study On Software Engineering Principles

Group 2
Govt. Engineering College, Sreekrishnapuram.

November 2009
1
 ASSIGNMENT

Topic Navigation of a Robot

GROUP MEMBERS ROLL NO

Anjali SP 8
STAFF IN CHARGE Anoop R 9
Archana Chandran 10
Miss. Shilpa Arjun CR 11
Department of Information Technology Arun K 12
Assia Shabeeba K 13
Aswathy Manomohan 14

2
 Acknowledgement

We express our sincere gratitude to Miss. Shilpa,(Department

of Information Technology) for her valuable suggestions and
guidance that has helped use greatly in our assignment preparation
and presentation. We are thankful to her for guidance in the
selection of the topic of our assignment.

We are thankful to Miss. Praveena,(Department of Information

Technology) for the help in the topics. We are also thankful to our
friends for their suggestions and wholehearted support.

Above all we thank God Almighty without whose immense

blessings I could not complete the assignment successfully.

Group Members

3
 Abstract
This assignment is conducted as a part of evaluation for the
subject Software Engineering. Teacher divided the class into groups
of seven each.

We were asked to choose a topic for case study. Our first task
was to take the most appropriate topic. Each member came up with
different topic, collected details about it. We then choose this
specific topic as it provides an excellent opening example. We are
also studying this as an example in “Object Oriented Design”.

Again we divided the task by assigning each member to collect

details regarding a specific principle. Everyone tried their level best.
We sat together and read each other’s data and organized it. Finally
everything was documented in a neat fashion on the allowed time.

4
 Contents

A. Introduction 6

B. Case Study : Robot Navigation 7

i. Rigor and formality 8
ii. Separation of concerns 16
iii. Modularity 20
iv. Abstraction 24
v. Anticipation of change 30
vi. Generality 33
vii. Incrementality 36

C. Conclusion 38

D. Bibliography 39

5
 Introduction

Principles form the basis of methods, techniques, methodologies

and tools.Principles become practice through methods and
techniques
• Often methods and techniques are packaged in a
methodology
• Methodologies can be enforced by tools

Principles apply to process and product

Tools

Methodologies
Methodologies

Methods
and techniques

Principles
Principles

A visual representation

Key principles
1. Rigor and formality
2. Separation of concerns
3. Modularity
4. Abstraction
5. Anticipation of change
6. Generality
7. Incrementality

6
 Case study (system engineering):
Robot Navigation

In many cases, the "software engineering" phase starts after
understanding and analyzing the "systems engineering” issues

The robot navigation illustrates the point

Fig 1.

7
 Fig 2

Before implementing directly to the hardware the software is

demonstrated on a display screen.

8
 Rigor & formality

Software engineering is a creative design activity, but it must be
practiced systematically

Rigor is a necessary complement to creativity that increases our

confidence in our developments

Formality is rigor at the highest degree

Software process driven and evaluated by mathematical laws

Examples: product

• Mathematical (formal) analysis of program correctness

Robotic design should be based on mathematical and physical

equations on “centre of gravity”, “velocity” etc.

• Systematic (rigorous) test data derivation

Test should be conducted to find answers to the questions like

“when to apply brakes when robot travels at a particular speed? ”.

Example: process

• Rigorous documentation of development steps helps project

management and assessment of timeliness

In programming we are using formal semantics and syntax of a

perticular language. We also use the documenting conventions
followed in that language which greatly increases readability and
understandibility. So others can easily work on the code.

9
The above code may be written by the Software-Development Manger to his
team.

Below are language conventions he used.

10
The team may use any programming paradigm as given below.

Given below is a sample program.

11

Quite relevant: it is a performance critical system

Define requirements
• A single advancement by the hominoid carries it exactly one square
forward (in the direction of its nose).

• It’s important that the hominoid visit every square on the path from
START to FINISH.

12
Fig 3. A path through the hominoid’s grid. Here ‘S’ denotes “starting point” and ‘F’ the “finishing
point”.

• It’s even more important that the hominoid does not hit a wall,
because then we'll look stupid and they won't let us install the
software in the actual hardware hominoid.

Later, verify their fulfillment

Hominoid navigation is an area where systematic (formal) design

methods have been applied

Fig 4.

This Layered Architecture also implements other principles like modularity,

separation of concerns etc.

13
Fig 5.

Fig 6.

14
 Fig 7 .

It is important that the robot navigate in its exact path. If it is not rigor it
affects maintainability.

15
 Separation of concerns

To dominate complexity, separate the issues to concentrate on

one at a time

"Divide & conquer" (divide et impera)

Supports parallelization of efforts and separation of

responsibilities

Example: process

Fig 8.

• Go through phases one after the other (as in waterfall or in Fig 8)

• Does separation of concerns by separating activities with respect to

time

Example: product
• Keep product requirements separate

 Functionality

 Performance

16
  User interface and usability

Try to separate, although some are strongly related

• safety

• performance

• usability

• cost

Cost reduction by using cheap material can make solution

unreliable

When designing operations no need to worry about hardware

implementation.

Separation of concerns is recognition of the need for human

beings to work within a limited context.

Although human capacity for forming abstractions appears to be
unlimited, it takes time and repetitive use for an abstraction to
become a useful tool; that is, to serve as a unit.

When specifying the behavior of a data structure component,
there are often two concerns that need to be dealt with: basic
functionality and support for data integrity.

A data structure component is often easier to use if these two
concerns are divided as much as possible into separate sets of
client functions.

It is certainly helpful to clients if the client documentation treats
the two concerns separately. Further, implementation
documentation and algorithm descriptions can profit from
separate treatment of basic algorithms and modifications for data
integrity and exception handling.

17

Software engineers must deal with complex values in attempting
to optimize the quality of a product. There are often efficient
algorithms for optimizing a single measurable quantity, but
problems requiring optimization of a combination of quantities
are almost always NP-complete.

Although it is not a proven fact, most experts in complexity theory
believe that NP-complete problems cannot be solved by
algorithms that run in polynomial time. In view of this, it makes
sense to separate handling of different values.

This can be done either by dealing with different values at
different times in the software development process, or by
structuring the design so that responsibility for achieving different
values is assigned to different components.
• As an example of this, run-time efficiency is one value that frequently
conflicts with other software values. For this reason, most software
engineers recommend dealing with efficiency as a separate concern.
After the software is design to meet other criteria, its run time can be
checked and analyzed to see where the time is being spent. If necessary,
the portions of code that are using the greatest part of the runtime can
be modified to improve the runtime.

Fig 9. 18
 Fig 10.

A robot has a plurality of components which can pivot relative to each other, in
particular robot arms. Changes in the separation between individual points of
the robot thereby occur. This must be taken into consideration when guiding
the operation cables for robot elements, in particular robot tools. They must
be able to accommodate changes in length while being loaded to as little an
extent as possible during motion of the robot so that they have high durability
and are not prematurely damaged.

19
 Modularity

The principle of modularity is a specialization of the principle of
separation of concerns.

Following the principle of modularity implies separating software

into components according to functionality and responsibility.

A complex system may be divided into simpler pieces called

modules

A system that is composed of modules is called modular

When dealing with a module we can ignore details of other

modules

Cohesion and coupling

• Each module should be highly cohesive

• Module understandable as a meaningful unit

• Components of a module are closely related to one another

• Modules should exhibit low coupling

• Modules have low interactions with others

• Understandable separately

(a) (b)

high coupling low coupling

20
 Fig 11.

Fig 12.

Coupling allows modules to see as “Black Boxes”.

21
Fig 13.

Navigation process decomposed into phases
• Position analysis

• Changing direction

 Turn left

 Turn right

• Advancing

 Forward

 Backward

Phases can be associated with modules and sub modules.

Module decomposition may be iterated

In java class can be considered as modules

Fig 14.

Below are modules based on hardware.

22
 Fig 15.

Fig 16.

23
 Abstraction

The principle of abstraction is another specialization of the
principle of separation of concerns.

Following the principle of abstraction implies separating the
behavior of software components from their implementation.

It requires learning to look at software and software components
from two points of view: what it does, and how it does it.

Design by contract is an important methodology for dealing with
abstraction.

Identify the important aspects of a phenomenon and ignore its
details

The type of abstraction to apply depends on purpose

Abstraction ignores details

• Example: equations describing complex circuit (e.g.,

amplifier) allows designer to reason about signal
amplification

• Equations may approximate description, ignoring details

that yield negligible effects (e.g., connectors assumed to be
ideal)

Abstraction yields models.The model can be a formal or

semiformal description

It is then possible to reason about the system by reasoning about

the model

Abstraction ignores details such as precision of number

representation or addressing mechanisms

24
Fig 17.

Fig 18.

25
 Fig 19.

Fig 20.

26
 Fig 21.

Fig 22.

27
Fig 23.

Fig 24.

28
 Fig 25.

In the above fig the joystick abstracts its movement.

In space explorer robots sometimes we may need to manually

control. Simple abstracted interfaces must be provided for that.

The usage of high level programming is itself an abstraction of

lower ones and they abstract hardware.

The modular view we provided does not specify the behavior of
the mechanical and electrical components they are abstracted
away.

Switches abstract circuits.

29
 Anticipation of change

Ability to support software evolution requires anticipating
potential future changes

It is the basis for software evolvability

Applied in many cases

In the organization of hardware and software we give roam for
updating. Operations we coded may have bugs; there may be more efficient
algorithms,

Consider possible changes of

• Hardware changes

There will be hardware degradation; new efficient ones may be

replaced in all cases program should adapt itself.

• New operations

For specific robots like “servant robot”, “worker robot”, “Dancing

robots”, etc there may be additional operations. We may want to
overcome obstacles than to avoid them, there must be space given
for these additional operations.

• Advanced devices

We may want to use IR cameras for ordinary ones, sliders or

bipedal for the wheel in all these cases if we didn’t coded
appropriately then we may have to completely recode the program.

• Different environments

The robot have to work on different environments like rough rocky

surface, grassy land, smooth floor or in different temperature,
humidity etc. All of these must be taken into consideration.

We separate more stable and necessary ones and package them in

core. This help in changing the unstable ones.

30
Fig 26. Shows robots working in different environments

31

Software developers, on the other hand, are familiar with a
technology that deals with data in an abstract way. They deal
with structures and algorithms without regard for the meaning
or importance of the data that is involved. A software
developer can think in terms of graphs and graph algorithms
without attaching concrete meaning to vertices and edges.

Software developers are learning the domain that the clients
work in. They are also learning the values of the client: what
form of data presentation is most useful to the client, what
kinds of data are crucial and require special protective
measures.

If the problem to be solved is complex then it is not reasonable
to assume that the best solution will be worked out in a short
period of time. The clients do, however, want a timely solution.
They want a reasonable solution soon; perfection can come
later. To develop a timely solution, software developers need
to know the requirements: how the software should behave.
The principle of anticipation of change recognizes the
complexity of the learning process for both software
developers and their clients. Preliminary requirements need to
be worked out early, but it should be possible to make changes
in the requirements as learning progresses.

Coupling is a major obstacle to change. If two components are
strongly coupled then it is likely that changing one will not work
without changing the other.

Cohesiveness has a positive effect on ease of change. Cohesive
components are easier to reuse when requirements change. If
a component has several tasks rolled up into one package, it is
likely that it will need to be split up when changes are made.

32
 Generality

The principle of generality is closely related to the principle of

anticipation of change.

It is important in designing software that is free from unnatural
restrictions and limitations.

While solving a problem, try to discover if it is an instance of a
more general problem whose solution can be reused in other
cases.

Carefully balance generality against performance and cost.

Sometimes a general problem is easier to solve than a special

case.

Parameterize with respect to target machine (by defining

intermediate code)

Develop general navigation tools (navigators) instead of just one

hominoid

Fig 27.

33
 Fig 28.

Instead of steering drive only try to include all possible two-

dimensional movements in the fig 28.

If we write a program to navigate in the tough conditions it

helps to cover all environmental navigation easy.

Develop a common navigation tool for robots as well as tele-

operated vehicles like in fig 30.

34
Fig 29.

Fig 30.

35
 Incrementality

In this process, you build the software in small increments; for
example, adding one use case at a time.

An incremental software development process simplifies
verification. If you develop software by adding small increments of
functionality then, for verification, you only need to deal with the
added portion. If there are any errors detected then they are
already partly isolated so they are much easier to correct.

A carefully planned incremental development process can also
ease the handling of changes in requirements. To do this, the
planning must identify use cases that are most likely to be
changed and put them towards the end of the development
process.

Process proceeds in a stepwise fashion (increments)

Examples (process)
• Deliver subsets of a system early to get early feedback from
expected users, and then add new features incrementally

• Deal first with functionality, and then turn to performance

• Deliver a first prototype and then incrementally add effort to turn

prototype into product

• Deliver first a simple version for a subset of the operations, then

increasingly larger subsets

• Deliver hominoid with little or no diagnostics/optimizations, and

then add diagnostics/optimizations

First develop navigation software turn away from obstacles then develop ones
which could overcome simple obstacles (fig 31).

First develop trajectory system with camera then integrate with it the GPS (fig
32).

36
 Fig 31.

Fig 32.

37
 Conclusion

Without using software engineering principles it would be

difficult to be usually needed to develop large programs to
accommodate multiple functions at various levels. The problem is
that the complexity and the difficulty levels of the programs increase
exponentially with their sizes and hence increase in development
time and effort.

All the major software developers like that of “operating

systems”, “games” all relay on these principles. Over the years it has
proved to be efficient.

From the above data we can conclude that the seven software
engineering principles are very much essential in the development of
large and complex software likes that of the robot-navigation.

38
 Bibliography

Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli Fundamentals of
Software Engineering, second edition, PHI Private Limited, 2008.

Meilir Page-Jones, Fundamentals of Object-Oriented Design in

UML, sixth edition, PEARSON Education, 2009.

Davide Brugali, Software Engineering for Experimental Robotics

Web Pages

• http://www.library.unisa.edu.au

• http://portal.acm.org

• http://www.nptel.iitm.ac.in

• http://portal.acm.org

• http://www.library.unisa.edu.au

• http://www.d.umn.edu

• http://www.pdf-search-engine.com

• http://www.infibeam.com

• http://ecs.victoria.ac.nz

• http://cisnet.mit.edu

• http://www.mouemagazine.com

• http://www.sciencedirect.com

• http://ekalavya.it.iitb.ac.in

• http://www.edutalks.org

• http://ebook30.com

• http://www.nptel.iitm.ac.in

• http://www.wikipedia.org

• http://images.google.com

39