Software Engineering Tools

and Practices
Chapter 1
 Software process

 A software process typically defines phases (or stages) and

steps we take within each phase to develop (good)
software.
 A software engineering process should provide a
disciplined yet flexible approach to assigning tasks and
responsibilities within a software development
organization.
 The goal is to ensure the production of high-quality
software that meets the needs of its end users within a
predictable schedule and budget.
 Software process

 An engineering process involves applying well understood

techniques in an organized and disciplined way
 Many well-accepted practices have been formally
standardized
 Software engineering techniques are needed because large
systems cannot be completely understood by one person
 Teamwork and co-ordination are required
 Key challenge: Dividing up the work and ensuring that the
parts of the system work properly together
 The end-product that is produced must be of sufficient quality
 Software practices

 Software practices are specific things we do as part of

the software development process
 That is, practices are activities that implement the
process.
Six software engineering practices

 Develop Iteratively
 Manage Requirements
 Use Component Architectures
 Model Visually (UML)
 Continuously Verify Quality
 Manage Change
Practice 1: Develop Iteratively

 Developing iteratively is a technique that is used to

deliver the functionality of a system in a successive
series of releases of increasing completeness.
 Each release is developed in a specific, fixed time
period called "iteration.”
 Each iteration is focused on identifying, defining and
analyzing some set of requirements, and designing,
building and testing software based on the
understanding of those requirements.
Practice 1: Develop Iteratively

 The earliest iterations address greatest risks. Each iteration

produces an executable release.
 Each iteration includes integration and test. Iterations help
to:
 resolve major risks before making large investments
 enable early objective feedback
 make testing and integration continuous
 focus the project on achievable short-term objective
milestones
 make it possible to deploy partial implementations of the
completed final system
Practice 2: Manage Requirements

 Managing requirements involves the translation of

stakeholder requests into a set of key stakeholder needs
and system features. These in turn are detailed into
specifications for functional and non-functional
requirements.
 Detailed specifications are translated into a design, user
documentation and tests.
 The requirements for the software are a key input to
testing.
 Use Cases represent a technique for defining requirements
in a way that focuses on the end-user goal.
Practice 2: Manage Requirements

 you can establish traceability relationships between those

elements. Traceability assists us to do many things,
including:
 Assess the project impact of a change in a requirement
 Assess the impact of a failure of a test on requirements (i.e., if
test fails, the requirement may not be satisfied)
 Manage the scope of the project
 Verify that all requirements of the system are fulfilled by the
implementation
 Verify that the application does only what it was intended to
do
 Manage change
 Practice 3: Use Component
Architectures

 Architecture is an aspect of design. It is about making

decisions on how the system will be built. But it is not
all of the design.
 The most important property of an architecture is
resilience -- flexibility in the face of change.
 To achieve it, architects must anticipate evolution in
both the problem domain and implementation
technologies to produce a design that can gracefully
accommodate such changes.
 Definition of a (Software)
Component:

 Process Definition: A non-trivial, nearly independent, and

replaceable part of a system that fulfills a clear function in
the context of a well-defined architecture. A component
conforms to and provides the physical realization of a set
of interfaces.
 UML Definition: A physical, replaceable part of a system
that packages implementation, and conforms to and
provides the realization of a set of interfaces. A
component represents a physical piece of implementation
of a system, including software code (source, binary or
executable) or equivalents such as scripts or command
files.
Practice 4: Model Visually (UML)

 A model is a simplification of reality that provides a complete

description of a system from a particular perspective. We build
models so that we can better understand the system we are
modeling. We build models of complex systems because we
cannot comprehend any such system in its entirety.
 Modeling is important because it helps the development team
visualize, specify, construct, and document the structure and
behavior of a system’s architecture.
 Using a standard modeling language such as the UML (the
Unified Modeling Language), different members of the
development team can communicate their decisions
unambiguously to one another.
 Practice 5: Continuously Verify
Quality

 Achieving quality is not simply about "meeting

requirements" or producing a product that meets user
needs and expectations.
 Quality also includes identifying the measures and criteria
(to demonstrate the achievement of quality), and the
implementation of a process to ensure that the resulting
product has achieved an appropriate degree of quality.
 Software testing is an important aspect of Software
Quality process. Software testing accounts for 30% to 50%
of software development costs in many organizations.
 Practice 6: Manage Change

 Establishing secure workspaces for each worker on the

project provides isolation from changes made in other
workspaces and control of all software artifacts -- models,
code, docs, tests etc.
 A key challenge to developing software-intensive systems
is the need to cope with multiple workers, organized into
different teams, possibly at different sites, all working
together on multiple iterations, releases, products, and
platforms. In the absence of disciplined control, the
development process rapidly degrades into chaos.
Progress can come to a stop.
 Unified Modeling Language

 The objective of the Unified Modeling Language is to

provide a common vocabulary of object-based terms and
diagramming techniques that is rich enough to model any
systems development project from analysis to design.
 The diagrams are broken into two major groupings: one
for modeling the structure of a system and one for
modeling behavior.
 Structure diagrams are used for representing the data and
static relationships that are in an information system.
 Behavior diagrams provide the analyst with a way to depict
the dynamic relationships among the instances or objects that
represent the business information system.
 Structure Diagrams Used to

Class Illustrate the relationships between classes modeled in the

system.
Object Illustrate the relationships between objects modeled in the
system.
Function when actual instances of the classes will better
communicate the model.
Package Group other UML elements together to form higher level
constructs.

Deployment Show the physical architecture of the system. Can also be used to
show software components being deployed onto the physical
architecture

Component Illustrate the physical relationships among the software

components.

Composite Structure Illustrate the internal structure of a class—i.e., the relationships

among the parts of a class.
 Behavioral Diagrams Used to
Activity Illustrate business work flows independent of classes, the flow of
activities in a use case, or detailed design of a method.
Sequence Model the behavior of objects within a use case. Focuses on the
time-based ordering of an activity.

Communication Model the behavior of objects within a use case. Focuses on the
communication among a set of collaborating objects of an activity.

Interaction Overview Illustrate an overview of the flow of control of a process.

Timing Illustrate the interaction that takes place among a set of objects and
the state changes.
Behavioral State Machine Examine the behavior of one class.

Protocol State Machine Examine the behavior of one class.

Use Case Capture business requirements for the system and to illustrate the
interaction between the system and its environment
 UML class diagrams

 UML class diagram is a picture of the classes in an

object oriented system their fields and methods
connections between the classes that interact or
inherit from each other.
 What are some things that are not represented in a
UML class diagram?
 Details of how the classes interact with each other
 Algorithmic details; how a particular behavior is
implemented.
 Class Structure

 class name in top of box

 write <<interface>> on top of interfaces' names
 use italics for an abstract class name
 Attributes (optional)
should include all fields of the object

attributes (fields, visibility name : type [count] =

instance variables): default_value
visibility: + public
#protected
-private
~ package (default)
/ derived
underline static attributes

attribute example: - balance : double = 0.00

Operations / methods (optional)

 may omit trivial (get/set) methods

 But don't omit any methods from an interface!
operations / methods: visibility name (parameters) : return_type
visibility: + public
#protected
-private
~ package (default)
„ underline static methods

method example: + distance(p1: Point, p2: Point): double

Relationships between classes
Construct Description Syntax

Association A relationship between two or more classifiers that involves

connections between their instances.

Aggregation A special form of association that specifies a whole–parts

relationship between the aggregate (whole) and the
components (parts).

Generalization A taxonomic relationship between a more general and a more

specific element.

Dependency A relationship between two modeling elements, in which a

change to one modeling element (the
independent element) will affect the other modeling element
(the dependent element).

Realization A relationship between a specification and its implementation.

 Generalization relationships

 Generalization (inheritance) relationships, hierarchies

drawn top-down with arrows pointing upward to
parent
 line/arrow styles differ, based on whether parent is
a(n):
class: solid line, black arrow

abstract class: solid line white arrow solid line, white arrow

interface: dashed line, white arrow

Generalization relationships
 Associational relationships

 The association keyword is “has”.

 This association relationship is further described by
the multiplicity concept.
1.multiplicity (how many are used) * ⇒ 0, 1, or more
„ 1 ⇒ 1 exactly
„ 2..4 ⇒ between 2 and 4, inclusive,
„ 3..* ⇒ 3 or more

2.name what relationship the objects have

3.navigability Direction
 Sequence Diagram

 Interaction Diagram is a series of diagram describing the

dynamic behavior of an object oriented system.
 Sequence Diagram is types of Interaction Diagram.
 Shows how processes operate with one another in what order.
 Illustrates how objects interact with each other.
 Emphasizes time ordering of the messages.
 Can model simple sequential flow, branching, iteration, recursion
and concurrency.
 Key parts of a Sequence Diagram:
 Participant: An object or entity that acts in the sequence
diagram.
 Message: Communication between the participants / objects.
 System Sequence Diagram

 A type of sequence diagram that shows (for a particular

scenario of a use case), the events that external actors
generate, their order, and possible inter-system events.
 SSD are visual summaries of the individual use cases.
 An SSD should show the following:
 External Actors
 Messages (methods) invoked by these actors.
 Return values associated with previous messages.
 Indication of any loop or iteration area.
Key Components of Sequence
Diagram
 A Sale Process Scenario

 The cashier is required to process any purchasing (sale) activity by the

customer. The customer will firstly put their goods on the cash counter. The
cashier will then enter the item ID (could be the barcode) and its
quantity, so that the system can give the description of the item and total
price. The process is repeated until all items are scanned and recorded as
sale. The process will end afterwards, and will require the customer to
pay the amount indicated.
 Analysis
1. Cashier starts a new sale.
2. Cashier enters item identifier (should be barcode of item).
3. System records sale item and presents item description, price and running total.
4. Cashier repeats steps 2 to 3 until all items processed.
5. System presents total.
6. Cashier informs the customer the total and asks for payment.
7. Customer pays and System handles payment.
System Sequence Diagram for
process sale
Sequence Diagram named “Make
New Sale”