This document discusses principles of modeling and construction in software engineering. It covers types of modeling including analysis and design models. It describes principles for different modeling stages like analysis modeling principles, design modeling principles, and construction principles. It also discusses testing principles like ensuring all tests are traceable to requirements and testing should progress from individual components to integrated parts of the system.

1. MODELING AND CONSTRUCTION PRINCIPLES IN
SOFTWARE ENGINEERING
BY,
S.SUBHALAKSHMI,
M.SC(CS)
NADAR SARASWATHI COLLEGE OF ARTS AND SCIENCE.

2. CONTENT:
MODELING
TYPES OF MODELING
PRINCIPLES OF MODELING
ANALYSIS MODELING PRINCIPLES
DESIGN MODELING PRINCIPLES
CONSTRUCTION PRINCIPLES
TESTING PRINCIPLES

3. MODELING:
Models are useful for better understanding of actual entity
to be built or design.
Models are represented at different levels of abstraction first
depict software from customer’s view point and later represent
software at more technical level.

4. TYPES OF MODELING:
There are two classes of models are created:-
1) Analysis model
2) Design model
Analysis Model:
Represent the customer requirement, which includes
algorithmic specifications of program or process. Analysis model
includes three different domains a) Information domain b)
Functional domain c) Behavioral domain

6. DESIGN MODEL:
Design model provides concentrate specification for the
construction of software. Design model includes
a) Architectural design
b) User interface design
c) component level details.

8. The principles of modeling :
PRINCIPLES 1.The primary goal of the software team is to built
software, not create models:
Agility means getting software to the customer in the
fastest possible time. Models that make this happen are
worth creating, but models that slow the process down or
provide little new insight should be avoided.

9. PRINCIPLES 2.Travel light-don’t create more models than you
need:
Every model that is created must be kept up-to-date as
changes occur. Create only those models that make it easier
and faster to construct the software.
PRINCIPLES 3. Strive to produce the simplest model that will
describe the problem or the software:

10. Don’t over build the software. By keeping models simple,
the resultant software will also be simple. The result is software
that is easier to integrate, easier to integrate, easier to test,
easier to maintain.
PRINCIPLES.4: Build models in away that makes them amenable to
change.
The problem with this attitude is that without a
reasonably complete requirements model, you’ll create

11. a design that will invariably miss important functions and
features.
PRINCIPLES.5 Be able to state an explicit purpose for each model
that is created:
Every time you create a model, ask yourself why you’re
doing so. If you can’t provide solid justification for the existence of
the model, don’t spend time on it.

12. PRINCIPLES.6 Adapt the models you develop to the system at
hand:
It may be necessary to adapt model notation or rules to
the application ; for example, a video game application might
require a different modeling technique.
PRINCIPLES.7 Try to build useful models, but forget about building
perfect models:

13. When building requirements and design models, a software
engineer reaches a point of diminishing returns.
Try to build useful models.
PRINCIPLES.8 Don’t become dogmatic about the syntax of the model.
If it communicates content successfully, representations is
secondary:
Although everyone on a software team should try to use
consistent notation during modeling, the most

14. important characteristic of the model is to communicate
information.
PRINCIPLES.9 If your instincts tell you a model isn’t right even
though it seems okay on paper, you probably have reason to be
concerned:
If some thing tells you that a design model is doomed to
fail you have reason to spend additional time examining the
model or developing a different one.

15. PRINCIPLES.10 Get feedback as soon as you can:
Every model should be reviewed by members of the
software team. The intent of these reviews is to provide feedback
that can be used to correct modeling mistakes, change
misinterpretations, and add features or functions that were
inadvertently omitted.

16. ANALYSIS MODELING PRINCIPLES:-
PRINCIPLES.1 The information domain of problem must be clearly
represented: –
Analysis model uses “data flow diagram “to show
information domain which includes following detail input flow
into system, output flow in system, data collection by data store to
collect data in system.

17. PRINCIPLES.2 The function of software must be defined clearly:-
Function are process those transform input flow to output
flow so specification must be clearly defined.
PRINCIPLES.3 Behavior of system must be defined clearly:-
Analysis model uses state transition diagram to represent
the behavior of system clearly.

18. PRINCIPLES.4 The clear hierarchy among information function and
behavior must be shown: –
Information, function and behavior of system must be
represented by using proper hierarchy which leads to easy design.
PRINCIPLES.5 Analysis should be clear enough to convert it into
design model: –
It analysis of requirement is clear and simple then it will
be easy for design.

19. DESIGN MODELING PRINCIPLES:-
PRINCIPLES.1 Design should be traceable from analysis model:
Using elements if analysis model is constructed.
PRINCIPLES.2 Consider a architecture of system to be built: –
Architectural design shows following Architectural design style
are as follow a) data concentrate Architecture b) data flow
Architecture c) main / subprogram Architecture.

20. PRINCIPLES.3 Data should be important rather than design of
functions: –
Data design shows relationship between different data
object shown by entity relationship between different data object
shown by entity relationship diagram so data modeling is
important.
PRINCIPLES.4 User interface design must satisfy all needs of user:-
Design must be simple and convenient to end user side.

21. PRINCIPLES.5 Internal as well as External Interface must be
designed: –
For proper flow of data among system or external
environment to system it is important to have all internal and
external interface proper design is required.
PRINCIPLES.6 Design module should be easy to understand:-
As simple modules are easy to test, debug and modify so
design should be simple.

22. PRINCIPLES.7 Cohesion measure functionally strength of module so
for proper design all function in single module should be highly
cohesive so that why Component level design should be
functionally independent.
PRINCIPLES.8 Accept that design modeling is iterative: –
Good design should be capable to the absorb all changes.

23. PRINCIPLES.9 Components required loosely coupled to the external
environment: –
The Component should be loosely coupled to one another
and to external environment in the modeling system.
CONSTRUCTION PRACTICE:
The construction activity encompasses a set of coding and
testing task that lead operational software that is ready for
delivery to the customer or end-user.

24. In modern software engineering work, coding may be:
1)the direct creation of programming language source code;
2)the automatic generation of source code using an
intermediate design-like representation of the component to be
built;
3)the automatic generation of executable code using a fourth
generation programming language.

25. CODING PRINCIPLES:
The principles and concepts that guide the coding task are
closely aligned programming style, programming language, and
programming methods.
However, there are a number of fundamental principles
that can be stated:

26. PREPARATION PRINCIPLES: Before you write one line of code, be
sure you:
1.Understand the problem you’re trying to solve.
2.Understand basic design principles and concepts.
3.Pick a programming language.
4.Select a programming environment that provides tools that
will make your work easier.
5.Create a set of unit tests that will be applied once the
compentent you code is completed.

27. CODING PRINCIPLES:As you begin writing code, be sure you:
1.Constrain your algorithm by following structured programming
practice.
2.Select data structure that will meet the needs of the design.
3.Understand the software architecture and create interfaces that
are consistent.

28. 4.Keep conditional statement as simple as possible.
5.Create nested loops in a way that makes them easily testable.
6.Select meaningful variable names and follow other local coding
standards.
7.Write code that is self-documenting.
8.Create a visual layout that aids understanding.

29. VALIDATION PRINCIPLES: After you’ve completed your first coding
pass, be sure you:
1.Conduct a code walkthrough when appropriate.
2.Perform unit tests and correct errors you’re uncovered.
3.Refactor the code.
TESTING PRINCIPLES:
Testing in a process of executing with the intent of finding
an error.

30. A good case is one that has a high probability of finding as
as-yet undiscovered error.
The Testing principles are:
PRINCIPLES.1 All tests should be traceable to customer
reqiurements:
The objective of software testing is uncovered.

31. PRINCIPLES.2 Tests should be planned long before testing
begins:
Test planning can began as soon as the analysis model is
complete and the design model has been solidified.
PRINCIPLES.3 The pare to principle applies to software testing:
Stated simply, the pareto principle implies that 80 percent
of all errors uncovered during traceable to 20 percent of all
program components.

32. PRINCIPLES.4 Testing should begin “in the small” and progress
toward testing “in the large”:
The first tests planned and executed generally focus on
individual components.
PRINCIPLES.5 Exhaustive testing is not possible:
The number of path permutations for even a moderately
sized program is exceptionally large. For this reason, it is
impossible to execute every combination of paths during testing.