This document discusses software engineering practices and tools, including the software crisis and issues like increasing complexity, poor quality, high costs and delays. It introduces Unified Modeling Language (UML) as a standard way to visually model software systems using diagrams. It describes different types of UML models including structural, behavioral and architectural modeling. It also discusses concepts like the software development life cycle, configuration management, revision control systems and how to create UML diagrams like use case diagrams and sequence diagrams.

1. 1
Course Title: Software Engineering Tools and Practices Course Code: SENG4091
Year: IV Semester: I
Introduction to software engineering practices
Software engineering practices are a broad array of concepts, principles, methods, and tools
that you must consider as software is planned and developed. Best Practices address the root
causes of poor software development. Software Development Best Practices are as follows
 Develop Iteratively.
 Manage Requirements.
 Use Component Based Architecture.
 Visually Model Software.
 Code Simplicity. Strive to keep your code simple.
 Testing. Continuously test from end to end.
 Code Coherence. Keep it consistent across your team.
 Code Reviews. Don't be shy, allow someone to check your code!
 Verify Software Quality.
 Control Changes to Software.
 Estimation. Set your time and budget estimates realistically.
Software Crisis
1. Size: Software is becoming more expensive and more complex with the growing
complexity and expectation out of software. For example, the code in the consumer
product is doubling every couple of years.
2. Quality: Many software products have poor quality, i.e., the software products defects
after putting into use due to ineffective testing technique. For example, Software testing
typically finds 25 errors per 1000 lines of code.
3. Cost: Software development is costly i.e. in terms of time taken to develop and the
money involved. For example, Development of the FAA's Advanced Automation System
cost over $700 per lines of code.
4. Delayed Delivery: Serious schedule overruns are common. Very often the software
takes longer than the estimated time to develop, which in turn leads to cost shooting
up. For example, one in four large-scale development projects is never completed.

2. 2
Source: The Standish Group International, Inc. (CHAOS research)
UML: Unified Modeling Language
UML is a visual language for developing software blue prints (designs). A blue print or design
represents the model. For example, while constructing buildings, a designer or architect
develops the building blueprints. Similarly, we can also develop blue prints for a software
system.
 UML stands for Unified Modeling Language. It is a standard visual modeling language
in the field of software engineering.
 UML was created by the Object Management Group (OMG) and UML 1.0 specification
draft was proposed to the OMG in January 1997.
 UML is different from the other common programming languages such as C++, Java,
COBOL, etc.
 UML is not a programming language but tools can be used to generate code in various
languages using UML diagrams. UML has a direct relation with object oriented
analysis and design.
UML MODELS
What Are The Three Types Of Modeling In UML?
It is very important to distinguish between the UML models. Different diagrams are used
for different types of UML modeling. There are three important types of UML modeling.
1. Structural Modeling
Structural modeling captures the static features of a system. They consist of the following
 Classes diagrams
 Objects diagrams
 Deployment diagrams
 Package diagrams
 Composite structure diagram
 Component diagram
They all represent the elements and the mechanism to assemble them. The structural
model never describes the dynamic behavior of the system. Class diagram is the most
widely used structural diagram.
Class Diagram
Class diagrams are the backbone of almost every object-oriented method, including UML.
They describe the static structure of a system. It shows the classes in a system, attributes,

3. 3
and operations of each class and the relationship between each class. In most modeling tools,
a class has three parts. Name at the top, attributes in the middle and operations or methods
at the bottom.
The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
The following points should be remembered while drawing a class diagram −
 The name of the class diagram should be meaningful to describe the aspect of the system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified
 For each class, minimum number of properties should be specified, as unnecessary
properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram.
 Finally, before making the final version, the diagram should be drawn on plain paper
and reworked as many times as possible to make it correct.
Object Diagram
Object diagrams describe the static structure of a system at a particular time. They can be
used to test class diagrams for accuracy. Object Diagrams, sometimes referred to as Instance
diagrams are very similar to class diagrams. Like class diagrams, they also show the
relationship between objects but they use real-world examples.
The purpose of the object diagram can be summarized as −
 Forward and reverse engineering.

4. 4
 Object relationships of a system
 Static view of an interaction.
 Understand object behavior and their relationship from practical perspective
Package Diagram
Package diagrams are a subset of class diagrams, but developers sometimes treat them as a
separate technique. Package diagrams organize elements of a system into related groups to
minimize dependencies between packages.
Composite Structure Diagram
Composite structure diagrams show the internal part of a class.
Component Diagram
Component diagrams describe the organization of physical software components, including
source code, run-time (binary) code, and executable. A component diagram displays the
structural relationship of components of a software system. These are mostly used when
working with complex systems with many components. Components communicate with
each other using interfaces. The interfaces are linked using connectors.
The purpose of the component diagram can be summarized as −
 Visualize the components of a system.
 Construct executable by using forward and reverse engineering.
 Describe the organization and relationships of the components.
Deployment Diagram
Deployment diagrams depict the physical resources in a system, including nodes,
components, and connections. A deployment diagram shows the hardware of your system
and the software in that hardware. Deployment diagrams are useful when your software
solution is deployed across multiple machines with each having a unique configuration.
The purpose of deployment diagrams can be described as −
 Visualize the hardware topology of a system.
 Describe the hardware components used to deploy software components.
 Describe the runtime processing nodes.
2. Behavioral Modeling
Behavioral model describes the interaction in the system. It represents the interaction
among the structural diagrams. Behavioral modeling shows the dynamic nature of the
system. They consist of the following −
 Activity diagrams
 Interaction diagrams
 Use case diagrams
All the above show the dynamic sequence of flow in a system.

5. 5
Use Case Diagram
Use Case diagrams are defined as diagrams that capture the system's functionality and
requirements coverage in UML.
HowtoDrawaUseCaseDiagram?
Following rules must be followed while drawing use-case for any system:
 Identify the Actors (role of users) of the system.
 The name of an actor or a use case must be meaningful and relevant to the system.
 Interaction of an actor with the use case must be defined clearly and in an understandable way.
 Comments must be used wherever they are required.
 If a use case or an actor has multiple relationships, then only significant interactions must be
displayed.
 Create use cases for every goal.
 Prioritize, review, estimate and validate the users.
Tips for drawing a use-case diagram
1. A use case diagram should be as simple as possible.
2. A use case diagram should be complete.
3. A use case diagram should represent all interactions with the use case.
4. If there are too many use cases or actors, then only the essential use cases should be
represented.
5. A use case diagram should describe at least a single module of a system.
6. If the use case diagram is large, then it should be generalized.
Use case diagrams comprise of −
 Use cases: Use case represents a set of actions performed by a system for a specific
goal.
 Actors: Actors are the users of a system.
 Relationships: Illustrate relationships between an actor and a use case with a simple
line, like dependency, generalization, and association
 System boundary: A system boundary defines the scope of the system. The systems that
use cases also need to be defined in the limits of the system. The system boundary is
shown as a rectangle that spans all use cases of the system.
Example
Let us consider an Automated Trading House System. We assume the following features of
the system −
 The trading house has transactions with two types of customers, individual
customers and corporate customers.
 The system allows the manager to manage customer accounts and answer any
queries posted by the customer.

6. 6
UML Use Case Diagram
Activity Diagram
 Activities: An activity indicates an action that performed in the system.
 Transitions: Transitions are represented by open arrow heads. Transitions are
used to indicate the flow among elements in the diagram.
 Decision Points: The logical branching is depicted by the decision points.
 States: A state is shown in a rounded rectangle. States are indicated to mention the
mile stones of processing in the activity diagrams.
Activity diagram is another important diagram in UML to describe the dynamic aspects of
the system. Activity diagram is basically a flowchart to represent the flow from one activity
to another activity. The activity can be described as an operation of the system. The control
flow is drawn from one operation to another. This flow can be sequential, branched, or
concurrent. Activity diagrams deal with all type of flow control by using different elements
such as fork, join, etc.
Purpose of Activity Diagrams
It captures the dynamic behavior of the system. Other four diagrams are used to show the
message flow from one object to another but activity diagram is used to show message flow
from one activity to another. Activity is a particular operation of the system. It does not
show any message flow from one activity to another.
The purpose of an activity diagram can be described as −
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

7. 7
How to Draw an Activity Diagram?
Before drawing an activity diagram, we should identify the following elements −
 Activities
 Association
 Conditions
 Constraints
Once the above-mentioned parameters are identified, we need to make a mental layout of
the entire flow. This mental layout is then transformed into an activity diagram. Following
is an example of an activity diagram for order management system. In the diagram, four
activities are identified which are associated with conditions. The activity diagram is made
to understand the flow of activities and is mainly used by the business users
Interaction Overview Diagram
Interaction overview diagrams are a combination of activity and sequence diagrams. They
model a sequence of actions and let you deconstruct more complex interactions into
manageable occurrences. You should use the same notation on interaction overview
diagrams that you would see on an activity diagram
Interaction diagrams can be used −
 To model the flow of control by time sequence.
 To model the flow of control by structural organizations.
 For forward engineering.
 For reverse engineering.
Sequence diagrams.

8. 8
Sequence diagrams, commonly used by developers, model the interactions between objects
in a single use case. In simpler words, a sequence diagram shows different parts of a system
work in a ‘sequence’ to get something done.
Benefits of sequence diagrams
Sequence diagrams can be useful references for businesses and other organizations. Try
drawing a sequence diagram to:
 Represent the details of a UML use case.
 Model the logic of a sophisticated procedure, function, or operation.
 See how objects and components interact with each other to complete a process.
 Plan and understand the detailed functionality of an existing or future scenario.
Purpose of Sequence Diagrams
The purpose of interaction diagram is −
 To capture the dynamic behavior of a system.
 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.
How to Draw a Sequence Diagram?
Following things are to be identified clearly before drawing the interaction diagram
 Objects taking part in the interaction.
 Message flows among the objects.
 The sequence in which the messages are flowing.
 Object organization.
Following are two interaction diagrams modeling the order management system. The first
diagram is a sequence diagram and the second is a collaboration diagram.
Eg. The sequence diagram has four objects (Customer, Order, SpecialOrder and
NormalOrder).
The following diagram shows the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. It is important to understand the time sequence
of message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm
() which is a method of SpecialOrder object and the last call is Dispatch () which is a method
of SpecialOrder object. The following diagram mainly describes the method calls from one
object to another, and this is also the actual scenario when the system is running.

9. 9
3. Architectural Modeling
Architectural model represents the overall framework of the system. It contains both
structural and behavioral elements of the system. Architectural model can be defined as the
blueprint of the entire system. Package diagram comes under architectural modeling.
A Revision Control System
A revision control system is also known as a version control system. Revision control
system (RCS) or Version control system (VCS) or Source code management (SCM)
stands for systems that allow software developers to manage application source code,
including its various revisions.
SCM uses archiving method or saves every change made to file. With the help of archiving or
save feature, it is possible to roll back to the previous version in case of issues. Changes to
these documents are usually identified by incrementing an associated number or letter code,
termed the "revision number", "revision level", or simply "revision" and associated
historically with the person making the change. A simple form of revision control, for
example, has the initial issue of a drawing assigned the revision number "1". When the first
change is made, the revision number is incremented to "2" and so on.

10. 10
Software Configuration Management
 Configuration Management helps organizations to systematically manage, organize, and
control the changes in the documents, codes, and other entities during the Software
Development Life Cycle.
 The primary goal of the SCM process is to increase productivity with minimal mistakes
 The main reason behind configuration management process is that there are multiple
people working on software which is continually updating. SCM helps establish
concurrency, synchronization, and version control.
 A baseline is a formally accepted version of a software configuration item
 Change control is a procedural method which ensures quality and consistency when
changes are made in the configuration object.
 Configuration status accounting tracks each release during the SCM process
 Software Configuration audits verify that all the software product satisfies the baseline
needs
 Project manager, Configuration manager, Developer, Auditor, and user are participants
in SCM process
 The SCM process planning begins at the early phases of a project.
Software Configuration Management Process
It uses the tools which keep that the necessary change has been implemented satisfactorily
to the appropriate component. The SCM process defines a number of tasks:
o Identification of objects in the software configuration
o Version Control
o Change Control
o Configuration Audit
o Status Reporting
Identification
Basic Object: Unit of Text created by a software engineer during analysis, design, code, or
test.
Aggregate Object: A collection of essential objects and other aggregate objects. Design
Specification is an aggregate object.
Version Control
Version Control combines procedures and tools to handle different version of configuration
objects that are generated during the software process.
Change Control
Change control is function of configuration management, which ensures that all changes
made to software system are consistent and made as per organizational rules and
regulations.

11. 11
A change in the configuration of product goes through following steps -
 Identification - A change request arrives from either internal or external source.
When change request is identified formally, it is properly documented. This section
should define identification schemas for information such as:
o Labeling and numbering documents and files
o Relationships between documents and files
o Addressing versions and releases
o Change Control Forms
o Various baselines for the project (product versioning)
 Validation - Validity of the change request is checked and its handling procedure is
confirmed.
 Analysis - The impact of change request is analyzed in terms of schedule, cost and
required efforts. Overall impact of the prospective change on system is analyzed.
 Execution - If the previous phase determines to execute the change request, this
phase take appropriate actions to execute the change, does a thorough revision if
necessary.
Close request - The change is verified for correct implementation and merging with the rest
of the system. This newly incorporated change in the software is documented properly and
the request is formally is closed.
Configuration Audit
SCM audits to verify that the software product satisfies the baselines requirements and
ensures that what is built and what is delivered.
SCM audits are the "watchdogs" that ensures that the integrity of the project's scope is
preserved.
Status Reporting
Configuration Status reporting (sometimes also called status accounting) providing accurate
status and current configuration data to developers, testers, end users, customers and
stakeholders through admin guides, user guides, FAQs, Release Notes, Installation Guide,
Configuration Guide, etc.
Software Configuration Management Plan
The SCMP (Software Configuration management planning) process planning begins at the
early phases of a project. The outcome of the planning phase is the SCM plan which might be
stretched or revised during the project.
 The SCMP can follow a public standard like the IEEE 828 or organization specific standard
 It defines the types of documents to be management and a document naming. Example
Test_v1

12. 12
 SCMP defines the person who will be responsible for the entire SCM process and
creation of baselines.
 Fix policies for version management & change control
 Define tools which can be used during the SCM process
 Configuration management database for recording configuration information.
User Interface Design
User interface design is also known as user interface engineering. User interface design
means the process of designing user interfaces for software and machines like a mobile
device, home appliances, computer, and another electronic device with the aim of increasing
usability and improving the user experience.
Graphical User Interface (GUI) Design Principles
Structure: Design should organize the user interface purposefully, in the meaningful and
usual based on precise, consistent models that are apparent and recognizable to users,
putting related things together and separating unrelated things, differentiating dissimilar
things and making similar things resemble one another. The structure principle is concerned
with overall user interface architecture.
Simplicity: The design should make the simple, common task easy, communicating clearly
and directly in the user's language, and providing good shortcuts that are meaningfully
related to longer procedures.vs Java
Visibility: The design should make all required options and materials for a given function
visible without distracting the user with extraneous or redundant data.
Feedback: The design should keep users informed of actions or interpretation, changes of
state or condition, and bugs or exceptions that are relevant and of interest to the user
through clear, concise, and unambiguous language familiar to users.
Tolerance: The design should be flexible and tolerant, decreasing the cost of errors.
Graphical User Interface Components
Interface components may involve:
1. Input controls
2. Navigational Components
3. Informational Components
4. Containers
Input Controls: Input Controls involve buttons, toggles, dropdown lists, checkboxes, date
fields, radio buttons, and text fields.
Navigational Components: Navigational components contain slider, tags, pagination,
search field, breadcrumb, and icons.
Informational Components: Informational Components contain tooltips, modal windows,
progress bar, icons, and notification message boxes.
Containers: Containers include accordion.

13. 13
Build Automation Tools
Build automation tools are part of the software development lifecycle where source code is
compiled into machine code by a build script. Once the code is completed it is integrated into
a shared environment. There it interacts with other software components built by other
developers. Typically build automation is completed with a scripting language that enables
the developer to link modules and processes within the compilation process. This scripting
encompasses several tasks including documentation, testing, compilation, and distribution
of the binary software code. Most popular build automation tools are open-source and free.
Advantages of Build Automation Tools
The advantages of build automation to software development projects include
 A necessary pre-condition for continuous integration and continuous testing
 Improve product quality
 Accelerate the compile and link processing
 Eliminate redundant tasks
 Minimize "bad builds"
 Eliminate dependencies on key personnel
 Have history of builds and releases in order to investigate issues
 Save time and money - because of the reasons listed above.
Build Automation Tools Capabilities
Build automation tools offer the following feature set:
 Extensive library of plugins
 Source code management tools
 Various available UI
 Compatibility with popular IDE
 Parallel tests and build execution
 Dependency management
 Collaborative debugging tools
 Incremental compilation (change only compiling)
 Rebuild minimization for faster build delivery
 Automated events & testing