Chapter Two

Software Engineering Practice

Contents
Software Engineering
Software Engineering Practice
Essence of Practice
Core principles of Software Engineering
Types of practice
 Software Engineering
 Software Engineering (SE) concerned with developing and
maintaining software systems that behave reliably and
efficiently, are affordable to develop and maintain, and satisfy
all the requirements that customers have defined for them.
 Development requires analysis and synthesis

 Analysis:- decompose a large problem into smaller,

understandable pieces.
• Abstraction is the key.
 Synthesis:- build(compose) software from smaller
building blocks.
• Composition is challenging.
 What is software engineering?
Solving problems.

The analysis process.

 What is software engineering?
Solving problems.

The synthesis process

 Software Engineering Practice
 Consists of a collection of concepts, principles, methods, and tools
that a software engineer calls upon a daily basis.
 Equips managers to manage software projects and software
engineer to build computer program.
 Provides necessary technical and management how to getting the
job done.

7
 The Essence of Practice
1. Understand the problem (communication and analysis)
 Who are the stakeholders?
 What are the unknowns? “Data, functions, features to solve the problem?”
 Can the problem be compartmentalized? “Smaller that may be easier
to understand?
 Can the problem be represented graphically? Can an analysis model be
created?
2. Plan a solution (modeling and software design)
 Have you seen a similar problem before?
 Has a similar problem been solved? If so, is the solution reusable?
 Can sub-problems be defined?
 Can you represent a solution in a manner that leads to effective
implementation?

8
 The Essence of Practice… cont’d
3. Carry out the plan (code generation)
 Does the solution conform to the plan?
 Is each component part of the solution probably correct?

4. Examine the result for accuracy (testing and quality assurance)

 Is it possible to test each component part of the solution?
 Does the solution produce results that conform to the data, functions,
features, and behavior that are required?

9
 Core Principles of Software Engineering
1. Remember the reason that the software exists (Reason It All Exists)
 The software should Provide value to the customer and the user and
satisfy requirements.
2. Keep It Simple All designs should be as simple as possible.
3. Maintain the vision of the project
 A clear vision is essential to the success of a S/W project.
4. Others will consume what you produce
 Always specify, design and implement knowing that someone else will
later have to understand and modify what you did.

10
 Cont…d
5. Be open to the Future
 Never design yourself into a corner; build software that can be easily
changed and adapted.
6. Plan Ahead for software Reuse.
 reuse reduces the cost and increases the value of the program and
components.
7. Think then act. Placing clear, complete thought before action almost
always produces better results

11
 Types of practices
1. Communication Practices
2. Planning Practices
3. Modeling Practices
I. Analysis Modeling Principles
II. Design Modeling Principles
4. Construction Practices
5. Testing Principles
6. Deployment Practices

12
 1. Communication practices
1. Listen: focus on the speaker’s words, rather than formulating your response to those words. Be a polite listener.
2. Prepare before you communicate: Spend the time to understand the problem before you meet with others
“research”.
3. Someone should facilitate the communication activity. Have a leader “moderator” to keep the conversation
moving in a productive direction.
4. Face-to-face communication is best, but also have a document or presentation to focus the discussion.
5. Take notes and document decisions.
6. Collaborate with the customer. Each small collaboration serves to build trust among team members and creates a
common goal for the team.
7. Stay focused, modularize your discussion. The facilitator should keep the conversation modular; leaving one
topic only after it has been resolved.
8. Draw pictures when things are unclear.

13
 2. Planning Practices
1. Understand the project scope. Scope provides the S/W team with a
destination.
2. Involve the customer (and other stakeholders) in the planning activity.
The customer defines priorities and establishes project constraints.
3. Recognize that planning is iterative. A plan must be adjusted to
accommodate changes.
4. Estimate based on what you know.
5. Consider risk as you define the plan.
6. Be realistic. Even the best S/W engineers make mistakes.
7. Adjust granularity as you plan. A fine granularity plan provides
significant work task detail that is planned over relatively short time
increments.
8. Define how quality will be achieved.
9. Define how you’ll accommodate changes.
10. Track what you’ve planned and make adjustments as required. 14
 3. Modeling Practices
3.1 Analysis Modeling Principles
• The information domain of a problem must be represented and
understood. The information domain encompasses the data that flow into
the system (end-users, other systems, or external devices), the data that
flow out of the system and the data stores that collect and organize
persistent data objects.
• Represent software functions. Functions can be described at many
different levels of abstraction, ranging from a general statement of purpose
to a detailed description of the processing elements that must be invoked.
• Represent software behavior. The behavior of the S/W is driven by the
interaction with the external environment.

The analysis task should move from essential information toward

implementation detail. Analysis begins by describing the problem from the
end-user perspective.
15
 Cont…d
3.2 Design Modeling Principles
The software design model is the equivalent of an architect’s plans for a house.
• Design must be traceable to the analysis model.
• The design model translates analysis model information into an architecture.
• Always consider architecture. S/W architecture is the skeleton of the system to be built.
• Focus on the design of data as it is as important as a design.
• Interfaces (both user and internal) must be designed.
• User interface design should be tuned to the needs of the end-user.
• Component-level design should exhibit functional independence.
• Components should be loosely coupled to one another and to the external environment.
• Design representation (models) should be easily understood.
• The design model should be developed iteratively. With each iteration, the designer should
strive for greater simplicity.

16
 4. Construction Practices
Construction is defined as being composed of both coding and testing.
4.1 coding principles
Preparation Principles: Before writing one line of code, be sure of:
1. Understand the problem you are trying to solve.
2. Understand the basic design principles.
3. Pick a programming language that meets the needs of the S/W to be built and the environment.
4. Select a programming environment that provides tool that will make your work easier.
5. Create a set of unit tests that will be applied once the component you code is completed.

Coding Principles: As you begin writing code, be sure you

6. Constrain your algorithm by following structured programming practice.
7. Select the proper data structure.
8. Understand the software architecture.
9. Keep conditional logic as simple as possible.
10. Create easily tested nested loops.
11. Write code that is self-documenting.
12. Create a visual layout.

Validation Principles: After you’ve completed your first coding pass, be sure you
13. Conduct a code walkthrough.
14. Perform unit test and correct errors.
15. Refactor the code.

17
 Construction Practices… con’d
4.2 Testing Principles
 The purpose of testing is to uncover defects.
 Testing is a process of executing a program with the intent of finding errors.
 A good test is one that has a high probability of finding an as-yet undiscovered error.
 A successful test is one that uncovers an as-yet-undiscovered error.

5. Deployment Practices
• Customer Expectations for the software must be managed. “Don’t promise more than you can
deliver.
• A complete delivery package should be assembled and tested.

• A support regime must be established before the software is delivered.

• Appropriate instructional materials must be provided to end-users.

• Buggy software should be fixed first, delivered later.

18
 Code generators
There are two main categories : passive or active.
• Passive code generators build the code once, then have nothing more to do
with the code.
• Active code generators keep track of the code during its lifecycle. It run on
code multiple times during the lifecycle. With Active Code generators, there
is code you can modify, and code that should only be modified by the code
generator.

19
 Code generation approaches
The main code generation approaches : visitor-based and template-based.
• The visitor-based approach is that the code is being generated while
iterating through textual representation of the model.
• The template-based approach is more commonly used because it could
provide more complex and nice code generation. It implies writing special
textual templates, which basically are a set of rules. These rules specify the way
of generating code from some specific model.

20
 Code generation types
1. Code mungers takes existing code and generates new code. Xdoclet is an
example of a code munger. Instead of rewriting the code by hand, a
program could translate the C source code into java source code.
2. Inline code expanders take existing code and elaborate certain sections of
that code. For example, Pro*C takes SQL code in a program and expands it
to c code.
3. Mixed code generators take model use code as input then build new code
and inserts it back into the original code. Wizards are often used to
implement this new code.
4. A partial class generator is different from the previous code generators. It
takes an abstract definition as input instead of code. It then outputs code.
For example, Expert coder convert UML models to CodeDOM objects.
5. Tier generators seem to be the most common type of code generator. Tier
generators build complete output code from an abstract definition.
21
 Code generation techniques
1. Templates and filtering defines that generalized source code fragments are
represented as textual templates. Variables are associated with the system
model.
2. Templates and meta-model technique is very similar to the previous one,
except the new meta-model of the system representation is being created
before the template is executed.
3. Frame processors the code is being specified with the help of objects -like
frames. Each frame owns a group of attributes called slots. Thus, during
code generation, the frames form the tree structure of the system source
code.
4. API-based generator is usually connected with a single programming
language. The source code is commonly specified with the help of
templates. It often have built-in compilers that are able to evaluate the
generated code at once.
22
 Code generation techniques
5. In-line generation technique determines that the program source code contains text
fragments, which at the time of compilation can be extended or not included into the
program at all. Such code generation technique is quite primitive, therefore it cannot be used
as the main one.
6. Code attributes technique defines that special text such as comments can be placed in
the existing source-code. This technique is commonly used to automatically generate
program documentation.
7. Code weaving technique states the following: some independent and non-related pieces
of text are manually written into the input file. At the same time it is also defined how all
these fragments should be joined together during the code generation process. Finally, all
these pieces would be processed and mixed to form the program source code.

23
 Synchronization among Modelling Views
The main views are the Model View, Diagram View, and Object Inspector.

 Model View

The Model View shows you the logical structure of your projects in a tree. Each project in a project group is a top-level
node on the model tree. Nested within each project tree-node, you will find nodes of UML packages.
 Diagram View

Diagram View shows diagrams (including class diagrams) defined in a model. In the Model View, double-click a diagram
node -- the diagram opens in the Diagram View.
 Object Inspector

The Modeling uses the Object Inspector to show the properties of a model element that you select in the Model View or
Diagram View.

24
 Synchronization between source code and UML
The Modeling's source code synchronization refers models
to:
 Source Code Visualization

The ability to scan your Delphi source code and map declarations within that code onto UML notations and then to
represent this mapping in graphical view.

 Source Code Generation

The opposite ability to generate the Delphi source code representing your graphical model.

The Modeling maps certain source code constructs (such as class declarations and implementations of interfaces) onto
their UML counterparts, which are then displayed on class diagrams in the Diagram View and on the modeling project
tree in the Model View. Thus, source code synchronization presents a graphical view of your source code and these
model tree and class diagrams reflect directly the source code.

25
 Cont…d
The Modeling immediately maps changes implemented in the model tree or class diagrams
into the existing Delphi source code:
 When you create a new or change an existing class diagram, the Modeling immediately
updates the corresponding Delphi source code to synchronize it with the class diagram.
 You can make changes directly in the class diagram in the Diagram View or in the model
tree in the Model View and the Modeling immediately reflects these changes in your
Delphi source code.

26
 Synchronization model
• In configuration management (CM), one has to control changes made to
software and documentation.
• This is called revision control, which manages multiple versions of the same
unit of information.
• Synchronization Models, also known as Configuration Management Models
(Feiler, 1991), describe methods to enable revision control through allowing
simultaneous, concurrent changes to individual files.

27
 Types of Synchronization model
There are 4 different types of synchronization model
1. Check-out/check-in
Files are stored individually in a repository from which they are checked out whenever the files are accessed, and checked
in when they have changed. This repository can store multiple versions of the files. Because these files can be
documentation or source code, but can also be a collection of files, the term Configuration item (CI) will be used from now
on. The basic mechanism used to prevent conflicts by simultaneous modifications is that of locking.

2. Composition
The composition model is an extension on the check-out/check-in model. This model allows developers to think in
configurations instead of individual files. Although the complete check-out/check-in model is represented in the
composition model, it enables the use of different strategies for updating through the use of improved support for the
management of configurations. A configuration is defined as being built up from a system model and version selection
rules.

28
 Types of Synchronization model
3. Long transactions
The long transactions model takes a broader approach by assuming that a system is built up out of logical changes. Its focus
is on the coordination and integration of these changes. Basically, it uses versions of configurations and versions of files. A
configuration is created based on a change request which is stored separately. Files in this configuration can be
synchronized using the check-out/check-in model. When the change is completed, the complete configuration is stored
back into the repository and integrated with other changes.

4. Change set
The change set model also works based on change requests and has a lot in common with the long transactions model.
However, it starts with a certain configuration as the basis for changes. This is then changed according to the independent
change requests that come in. New configurations of the product are then created by applying sets of the independently
stored changes on the baseline version.

This entry covers the check-out/check-in synchronization model, including a meta-model (a process-data diagram).

29
 Source code management or version control
SCMs are used to give versions/revisions to the program. Each version is given a timestamp and
includes the person responsible for the change. Even various versions can be compared and merged
with other versions. This is why SCM is also referred to Version Control, Revision Control or Source
Control.

Example:

Ankesh_Resume_Sept2017.doc

Ankesh_Resume_Dec2017.doc

With Source Code Management, you can collaborate with your team or isolate your code and make
changes without hampering the changes made by your teammates until the code is ready. Even the
troubleshooting becomes easy, as you know who made the changes and what those changes are.

30
 Source code management or version control
Features of source code management

 Authenticated access for commits

 Revision history on files
 Atomic commits of multiple files
 Versioning/Tagging

Why do we need source code management?

 Backup and Restore – Files can be saved at any moment and can be restored from the last saved.
 Synchronization – Programmers can get the latest code and fetch the up-to-date codes from the repository.
 Short-Term Undo – Working with a file and messed it up. We can do a short-term undo to the last known version.
 Long-Term Undo – It helps when we have to make a release version rollback.
 Track Changes – We can track the changes as when anyone is making any change, he can leave a commit message.
 Ownership – With every commit made to the master branch, it will ask the owner permission to merge it.
 Branching and Merging – You can create a branch of your source code and create the changes. Once the changes are
approved, you can merge it with the master branch.
31
 Types of version control systems
Centralized and Decentralized (or Distributed).

CENTRALIZED VERSION CONTROL

it works in a client and server relationship. The

repository is located in one place and allows access to
multiple clients.
It is very similar to FTP where you have FTP clients,
which connect to FTP server. Here all the user changes
and commits have to pass through the central server. For
Ex: Subversion.

32
 Types of version control systems
The benefits of centralized version control are:
 It is easy to understand.
 There are more GUI and IDE clients.
 You have more control over the users and access.

We do have drawbacks also

 It is dependent on the access to the server.

 It can be slower because every command from the client has to pass the server.
 Branching and merging strategies are difficult to use.

33
 DECENTRALIZED VERSION CONTROL
In DVC, each user has their own copy of the entire repository as well as
the files and history. For Ex: Git and Mercurial
The benefits of distributed version control are:
• More powerful and easy change tracking.
• No need of a centralized server. Most of the functionalities
work in offline mode also apart from sharing the repositories.
• Branching and merging strategies are more easy and reliable.
• It is faster than the other one.
Though we have drawbacks.
• It is harder to understand.
• It is new, so less GUI clients.
• It is easier to make mistakes until you are familiar with the
model.
34
 How revisions are made…. Cont’d
Revision control systems are usually hosted on a networked server. After the repository is set up, using it generally involves the
following steps: (Refer this link: https://www.computerhope.com/jargon/r/revision-control.htm)

1. If the developer has created a new file that should become part of the project, the file must be added to the repository. The file is
uploaded to the repository, and anyone else working on the project can see and use the file.

2. If the developer wants to edit a file that is already part of the project, the file must be checked out. The act of checking out downloads
the desired revision of the file to the developer's local version of the project. Usually, the revision that a developer wants to edit is the
most recent revision: this revision is known as the "head".

3. After the developer edits the file locally and is ready to add it to the official version of the project, the file can be checked in. This action
is also known as making a commit. The developer is asked to write a summary of what changes were made and why. These comments,
with the updated version of the file, are uploaded to the repository.

4. If someone else has checked in revisions to the same file since the last time the developer checked it out, the system announces that there
are conflicts. It calculates the differences line-by-line, and the developers who made the changes must agree upon how their individual
changes should be merged. The merging is usually done manually: the developers compare the conflicting versions and decide how to
resolve them into one document.

5. If there are no conflicts, the new version is updated in the repository, and the entire project receives a new revision number, permanently
and uniquely identifying its current state.
35