What is Software Engineering?

 Software Engineering is a Model Activity.

 Software Engineering is a Problem solving Activity.
 Software Engineering is a Knowledge Acquisition Activity.
 Software Engineering is a Rational driven Activity.
 Model activity:

 A Model is an abstract representation of a system that enables us to answer questions about

the system .

 Models are useful when dealing with Systems that are too large, too small, too complicated
or too expensive to experience.

 Models also allow us to visualize and understand systems that either No longer exists or that
are only claimed to exists .

 Software engineer need to Understand the environment in which the system has to operate.
eg: For train traffic Control System - train the Signaling
Stock trading systems – trading rules
 It doesn't mean they should become a fully certified train dispatcher (or) stock broker, they
need to learn the application domain concepts that are relevant to the System.

 Second, Software engineers the need to Understand the systems they could build to
evaluate different solutions and trade-offs.

 Object-oriented Methods combine the application domain and solution domain Modeling
activities into one application domain is first modeled as Cat of objects and relationships.

 This model is then used by the system to represent the real world concepts it Manipulates.

 Solution domain concepts are also Modeled as objects.

 Problem Solving

 Engineers Search for an appropriate Solution, often by trail and error,

evaluating alternatives empirically, with limited resources and
incomplete knowledge .

 Engineering Method includes 5 Steps.

1. Formulate the problems

2. Analyze the problem.
3. Search for solutions.
4. Decide on the appropriate solution
5. Specify the solution
 OOSE includes fix development activities

 Requirements elicitation
 Analysis
 System Design
 Objects
 Implementation
 Testing
 Knowledge Acquisition

 A Common Mistake that Solution Engineers and Managers Make is to assume that the acquisition of
knowledge needed to develop a System is linear

 Knowledge acquisition is non -Linear Process .

 The addition of a new piece of information May invalidate all the knowledge we have acquired for the
understanding of a system.

 There are several software processes that deal with this problem by avoiding the sequential dependencies
inherent in the waterfall model.

 Risk based development attempts to anticipate surprises late in a project by identifying the high risk
components.

 Issue Based development attempts to remove the linearity altogether - it executed in parallel.

 Any development activity can influence any other acitivity

 Rationale

 A typical task of software engineers is to change a currently operational software system to

incorporate this new enabling technology.

 To change the system, it is not enough to understand its current component and behaviour.

 It is also necessary to capture and Understand the context in which each design decision was
Made.
Software Engineering Concepts

Rectangle – Concept
Line – relationship
Diamond - aggregation
 Participants and Roles

Developing a software system requires the collaboration of many peoples with

different background and interest.

Client – order and pays for the system

Developer - construct the system
Project manager - plans and budgets the project and coordinates the developers
and the client
End users – supported by the system

We refer to all the persons involved in the project as participants.

We refer to a set of responsibilities in the project as a role.
A role is associated with a set of tasks.
 Ticket Distributor project

Role Responsibilites Examples

client Provide high quality Train Company
requirements
Define scope of the project
user User is responsible for Travelers
providing domain knowledge
about current user tasks
Manager Responsible for work boss
organization such as hiring,
assigning, monitoring and
managing the resources

Human factors Responsible for usability of

Specialist the system
Developer Construction of the system
Technical Writer Documentation delivered to
the client
 Systems and Models

System – collection of interconnected parts.

Modeling - deal with complexity by ignoring irrelevant details

TicketDistributor for underground train is a system.

Blue print is Schematics of its electrical wiring , and object models of its
software are models

Development project is itself a system that can be modeled.

 Work Products

It is an artifact that is produced during the development

• Internal work product – projects internal composition

• Deliverable – delivered to the client

Specification Describes the system from users point of view.

D Contractual doc between project and the client
Operation Manual It is responsible for installing and configuring
D
Status Report Given time the tasks have been completed
I
Test Manual Test plan and results produced by the Tester
I
 Activities , Tasks and Resources

Activity - is a set of tasks that is performed toward a specific purpose.

Eg: Requirement Elicitation – define with the client what the system will do
Delivery
Management

A task represents an atomic unit of work that can be managed.

Resources are assets that are used to accomplish work.

 SOFTWARE ENGINEERING DEVELOPMENT ACTIVITIES

• Requirements Elicitation

• Analysis

• System Design

• Object Design

• Implementation

• Testing
 Requirements Elicitation

 client and developers define the purpose of the system.

 The result of this activity is a description of the system in terms of actors and use cases.

 Actors represent the external entities that interact with the system.

 Actors include roles such as end users, other computers the system needs to deal with
(e.g., a central bank computer, a network), and the environment (e.g., a chemical
process).

 Use cases are general sequences of events that describe all the possible actions between
an actor and the system for a given piece of functionality.
 Analysis
 During analysis, developers aim to produce a model of the system that is correct, complete,
consistent, and unambiguous.

 Developers transform the use cases produced during requirements elicitation into an object model
that completely describes the system.

 During this activity, developers discover ambiguities and inconsistencies in the use case model
that they resolve with the client.

 The result of analysis is a system model annotated with attributes, operations, and associations.

 The system model can be described in terms of its structure and its dynamic interoperation.
 System Design

During system design, developers define the design goals of the project and decompose the system into
smaller subsystems that can be realized by individual teams.

Developers also select strategies for building the system, such as the hardware/software platform on
which the system will run.

The result of system design is a clear description of each of these strategies, a subsystem
decomposition, and a deployment diagram representing the hardware/software mapping of the system.
 Object Design

During object design, developers define solution domain objects to bridge the gap between the analysis model and
the hardware/software platform defined during system design.

This includes precisely describing object and subsystem interfaces.

Implementation

During implementation, developers translate the solution domain model into source code

Testing

During testing, developers find differences between the system and its models by executing the system (or parts of
it) with sample input data sets.
 Managing Software Development

Management activities focus on

 planning the project,
 monitoring its status,
 Tracking changes, and
 coordinating resources
such that a high-quality product is delivered on time and within budget.

Management activities not only involve managers, but also most of the other project
participants as well
Communication includes the exchange of models and documents about the system
and its application domain, reporting the status of work products, providing
feedback on the quality of work products, raising and negotiating issues, and
communicating decisions.
 Rationale Management

• Rationale is the justification of decisions.

• Given a decision, its rationale includes the problem that it addresses, the
alternatives that developers considered, the criteria that developers used to
evaluate the alternatives, the debate developers went through to achieve
consensus, and the decision. Rationale is the most important information
developers need when changing the system.
• If a criterion changes, developers can reevaluate all decisions that depend
on this criterion.
• If a new alternative becomes available, it can be compared with all the
other alternatives that were already evaluated.
Software Configuration Management

• Software configuration management is the process that monitors and

controls changes in work products.

• Change pervades software development. Requirements change as

the client requests new features and as developers improve their
understanding of the application domain.

• The hardware/software platform on which the system is built

changes as new technology becomes available
Project Management

Project management does not produce any artifact of its own.

Instead, project management includes the oversight activities that
ensure the delivery of a high-quality system on time and within
budget.
Software Life Cycle
we describe software engineering as a modeling activity. Developers
build models of the application and solution domains to deal with their
complexity. By ignoring irrelevant details and focusing only on what is
relevant to a specific issue, developers can more effectively resolve
issues and answer questions.
 UML

UML is a notation that resulted from the unification of

 OMT
 BOOCH
 OOSE

The goal of UML is to provide a standard notation that can be used by all OO
methods and to select and integrate the best elements of precursor notations.

Eg: UML includes the use case diagram introduced by OOSE and uses the many
features of the OMT class diagrams.
 System Development focuses on three Models

Functional Model – represented in UML with use case diagram – it describes the
functionality of the system from the users point of view.

Object Model – represented in UML with class diagram – describes the structure
of the system in terms of object , attributes and associations and operations.

Dynamic Model - represented in UML with interaction diagram , state machine

and activity diagram – describes the internal behaviour of the system

Interaction – sequence of messages exchanged among objects

State - describes in terms of states of an individual object and possible transition
Activity – describes in terms of control and data flows
 OVERVIEW OF UML

• Use Case Diagram

• Class Diagram

• Interaction Diagram

• State Machine Diagram

• Activity Diagram
 USE CASE DIAGRAM

Use cases are used during requirement elicitation and analysis to represent the
functionality of the system.

Uses cases focuses on the behaviour of the system from an external point of view.

Use case – function provided by the system

Actor – entity that interacts with the system

NOTATIONS AND SYMBOLS OF UML DIAGRAMS

System
Draw your system's boundaries using a rectangle that contains use cases.
Place Actors outside the system's boundaries.

Use Case
Draw use cases using ovals. Label with ovals with verbs that represent the system's
functions.

Actors
Actors are the users of a system. When one system is the actor of another system, label the
actor system with the actor stereotype.

Relationships

Illustrate relationships between an actor and a use case with a simple line. For relationships
among use cases, use arrows labeled either "uses" or "extends." A "uses" relationship indicates
that one use case is needed by another in order to perform a task.
An "extends" relationship indicates alternative options under a certain use case.
 CLASS DIAGRAM

It is used to describe the structure of the system.

Class diagrams describes the system in terms of objects, classes, attributes ,

operations and their associations.
Active Class

 Active classes initiate and control the flow of activity,

 while passive classes store data and serve other classes.
 Illustrate active classes with a thicker border.

Visibility

Use visibility markers to signify who can access the information contained within a class.
 Associations

Associations represent static relationships between classes.

Place association names above, on, or below the association line.

Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an
association.
Multiplicity (Cardinality)

These symbols indicate the number of instances of one class linked to one
instance of the other class.
constraints
Place constraints inside curly braces {}.
Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and
Class B, its part. Illustrate composition with a filled diamond.

Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more
important role than the "part" class, but the two classes are not dependent on each other.
 Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship between
two classes where one class is a specialized version of another.
INTERACTION DIAGRAM

It is used to formalize the dynamic behaviour of the system and to visualize the communication of
objects

Sequence Diagram
The sequence diagram represents the flow of messages in the system
Class roles
Class roles describe the way an object will behave in context. Use the UML object symbol to
illustrate class roles, but don't list object attributes.
Activation
Activation boxes represent the time an object needs to complete a task.
Messages

Messages are arrows that represent communication between objects. Use half-arrowed
lines to represent asynchronous messages. Asynchronous messages are sent from an object
that will not wait for a response from the receiver before continuing its tasks.
Lifielines

Lifelines are vertical dashed lines that indicate the object's presence over
time.The notation for a Lifeline is a vertical dotted line extending from an object.
 STATE MACHINE:

 A state chart diagram shows the behavior of classes in response to external stimuli.

 This diagram models the dynamic flow of control from state to state within a system.

It describes the dynamic behaviour of an individual object as a number of states and

transitions between these states.

A state represents a particular set of values for an objects

Given a state , a transition represents a future state the objects can move to and the
condition associated with the change of state.
States

States represent situations during the life of an object.

Transition

A solid arrow represents the path between different states of an object. Label the transition with
the event that triggered it and the action that results from it.
 Activity Diagram

Activity diagrams illustrate the dynamic nature of a system by modeling the flow of
control from activity to activity.

An activity represents an operation on some class in the system that results in a

change in the state of the system.

Typically, activity diagrams are used to model workflow or business processes and
internal operation.
 Action states
Action states represent the no interruptible actions of
objects.

Action Flow

Action flow arrows illustrate the relationships among action states.

 Object Flow

Object flow refers to the creation and modification of objects by activities .

Initial State

Final State

An arrow pointing to a filled circle nested inside another circle represents the final action state.

Branching

A diamond represents a decision with alternate paths.

Synchronization

A synchronization bar helps illustrate parallel transitions.

Swim lanes

Swim lanes group related activities into one column

Package Diagrams

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.
Component Diagrams

Component diagrams describe the organization of physical software

components, including source code, run-time (binary) code, and executables.
Deployment Diagrams

Deployment diagrams depict the physical resources in a system,

including nodes, components, and connections.
 Project Organization

Relationship among participants and between them and

Tasks,
Schedule and
Work product
 Team based organization

In this participants are grouped into teams, where a team is a small set of participants
working on the same activity or task.
 Simple Project Organization

Project participants interact with each other. The three major types of interaction in a
project are:

 Reporting – status
 Decision – propagating decision
 Communication
Hierarchical Organization

both status and decision information are unidirectional; that is, decisions are always made at the root
of the organization and passed via the interaction association to the leaves of the organization.
 Overview of Project

Project consists of 4 components

work product – any item produced by project (piece of code, model or a

document.
Work product produced for the client as deliverables.

Schedule – specifies when work on the project should be accomplished

Participant – any person participating in a project

Task – work to be performed by a project participant

 Project Phases

Definition Phase
Project manager
Possible client
Key project member
Software architect
Definition Phase

Two main areas to be focused

Initial understanding of the software architecture – sub system , decomposition and the
project in particular schedule , the work to be performed and the resource required

Documented in three documents

• The problem statement

• Initial software architecture document

• Initial software project management plan

Project start phase

Project manager sets up the

• Project infrastructure,
• Hires participants and organizes them in teams,
• Define milestones
• Starts the project

Project definition and project start phases are made by the project manager
Steady state phase

Participants develop the system

Termination phase

Project outcome is delivered to the client and the project history is collected.
 Communication

Planned and unplanned events

 Problem inspection
 Status meeting
 Peer reviews
 Client and project reviews
 Releases

 Requests for clarification

 Requests for change
 Issue resolution
UNIT II
 Requirements elicitation
Requirements elicitation focuses on describing the purpose of the system.

The client, the developers, and the users identify a problem area and define a system that
addresses the problem. Such a definition is called a requirements specification and serves as a
contract between the client and the developers.

The requirements specification is structured and formalized during analysis to produce an

analysis model.
Both requirements specification and analysis model represent the same information. They
differ only in the language and notation they use; the requirements specification is written
in natural language, whereas the analysis model is usually expressed in a formal or
semiformal notation.

The requirements specification supports the communication with the client and users. The
analysis model supports the communication among developers.

The models represent the same aspects of the system, requirements elicitation and analysis
occur concurrently and iteratively.
Requirements elicitation includes the following activities

 Identifying actors.
 Identifying scenarios.
 Identifying use cases.
 Refining use cases.
 Identifying relationships among use cases.
 Identifying nonfunctional requirements.
 Requirements Elicitation Concepts

 Functional Requirements
 Nonfunctional Requirements
 Completeness, Consistency, Clarity, and Correctness
 Realism, Verifiability, and Traceability
 Greenfield Engineering, Reengineering, and Interface Engineering
 Functional requirements

Functional requirements describe the interactions between the system and its
environment independent of its implementation.

The environment includes the user and any other external system with which the
system interacts.

Eg: SatWatch is a wrist watch that displays the time based on its current location. SatWatch uses
GPS satellites to determine its location and internal data structures to convert this location into a
time zone.
The above functional requirements focus only on the possible interactions between SatWatch
and its external world (i.e., the watch owner, GPS, and WebifyWatch). The above description
does not focus on any of the implementation details (e.g., processor, language, display
technology)
 NonFunctional requirements

Nonfunctional requirements describe aspects of the system that are not directly
related to the functional behavior of the system.

 Usability
 Reliability
 Performance
 Supportability
 Completeness, Consistency, Clarity, and Correctness
Requirements are continuously validated with the client and the user.

Validation is a critical step in the development process

Requirement validation involves checking that the specification is complete, consistent, unambiguous,
and correct.

It is complete if all possible scenarios through the system are described, including exceptional behavior
(i.e., all aspects of the system are represented in the requirements model).

The requirements specification is consistent if it does not contradict itself.

The requirements specification is unambiguous if exactly one system is defined (i.e., it is not possible
to interpret the specification two or more different ways).
 Realism, Verifiability, and Traceability

Three more desirable properties of a requirements specification are that it be realistic,

verifiable, and traceable.

The requirements specification is realistic if the system can be implemented within

constraints.

The requirements specification is verifiable if, once the system is built, repeatable
tests can be designed to demonstrate that the system fulfills the requirements
specification.
 Greenfield Engineering, Reengineering, and Interface Engineering

In greenfield engineering, the development starts from scratch—no prior system

exists—so the requirements are extracted from the users and the client.

A reengineering project is the redesign and reimplementation of an existing system

triggered by technology enablers or by business processes

An interface engineering project is the redesign of the user interface of an existing

system.
 Analysis

Analysis focuses on producing a model of the system, called the analysis model,
which is correct, complete, consistent, and verifiable.
The analysis model is composed of three individual models:

functional model, represented by use cases and scenarios,

analysis object model, represented by class and object diagrams, and

dynamic model, represented by state machine and sequence diagrams

 Analysis Concepts

 Analysis Object Models and Dynamic Models

 Entity, Boundary, and Control Objects
 Generalization and Specialization
 Analysis Object Models and Dynamic Models

The analysis model represents the system under development from the
user’s point of view.

The analysis object model is a part of the analysis model and focuses on the
individual concepts that are manipulated by the system, their properties and
their relationships.

The dynamic model focuses on the behavior of the system.

 Entity, Boundary, and Control Objects

The analysis object model consists of entity, boundary, and control objects .

 Entity objects represent the persistent information tracked by the system.

 Boundary objects represent the interactions between the actors and the system.

 Control objects are in charge of realizing use cases.

 Generalization and Specialization

Generalization is the modeling activity that identifies abstract concepts from

lower-level ones.

Specialization is the activity that identifies more specific concepts from a

high-level one.
 Analysis Activities:
It transform the use cases and scenarios produced during requirements elicitation
into an analysis model.
Analysis activities include:
 Identifying Entity Objects
 Identifying Boundary Objects
 Identifying Control Objects
 Mapping Use Cases to Objects with Sequence Diagrams
 Modeling Interactions among Objects with CRC Cards
 Identifying Associations
 Identifying Aggregates
 Identifying Attributes
 Modeling State-Dependent Behavior of Individual Objects
 Modeling Inheritance Relationships
 Reviewing the Analysis Model
UNIT III
System design is the transformation of an analysis model into a system design model.

During system design, developers

 define the design goals of the project and
 decompose the system into smaller subsystems
 Developers also select strategies for building the system,
such as the
 hardware/software strategy,
 the persistent data management strategy,
 the global control flow,
 the access control policy, and
 the handling of boundary conditions.

The result of system design is a model that includes a subsystem decomposition

and a clear description of each of these strategies.
System design is not algorithmic. Developers have to make trade-offs among many
design goals that often conflict with each other

System design is decomposed into several activities, each addressing part of the overall
problem of decomposing the system:

• Identify design goals. Developers identify and prioritize the qualities of the system that
they should optimize.
•Design the initial subsystem decomposition. Developers decompose the system into
smaller parts based on the use case and analysis models. Developers use standard
architectural styles as a starting point during this activity.
•Refine the subsystem decomposition to address the design goals. The initial
decomposition usually does not satisfy all design goals. Developers refine it until all
goals are satisfied.
System design, object design, and implementation constitute the construction of
the system.

During these three activities, developers bridge the gap between the requirements
specification, and the system that is delivered to the users.

System design is the first step in this process and focuses on decomposing the
system into manageable parts.

During requirements elicitation and analysis, we concentrated on the purpose and

the functionality of the system.

During system design, we focus on the processes, data structures, and software
and hardware components necessary to implement it.
A Floor Plan Example

a number of functional requirements:

 the kitchen should be close to the dining room and the garage,
 the bathroom should be close to the bedrooms, and so on.

The architect can also rely on a number of standards when establishing the
dimensions of each room and the location of the door:

kitchen cabinets come in fixed increments and beds come in standard sizes.

the architect does not need to know the exact contents of each room and the layout
of the furniture; on the contrary, these decisions should be delayed and left to the
client.
This house should have two bedrooms, a study, a kitchen, and a living room
area.

The overall distance the occupants walk every day should be minimized.

The use of daylight should be maximized

In First Version , we find that the dining room is too far from the kitchen.

In the second revision, we find that the kitchen and the stairs are too far from the entrance door.
 SYSTEM DESIGN CONCEPTS

Subsystem decompositions and their properties.

 Subsystems and Classes

 Services and Subsystem Interfaces
 Coupling and Cohesion
 Layers and Partitions
 Architectural Styles
 Subsystem and classes

A subsystem is a replaceable part of the system with well-defined interfaces that

encapsulates the state and behavior of its contained classes.

By decomposing the system into relatively independent subsystems, concurrent

teams can work on individual subsystems with minimal communication overhead.

In the case of complex subsystems, we recursively apply this principle and

decompose a subsystem into simpler subsystems
 Accident Management System

realizing the
user interface
Realizing user
for the
interface for the
FieldOfficer
dispatcher

depicting Maps and

Locations; responsible for
the creation,
modification, and
storage of
Incidents
communication
between FieldOfficer
terminals and , responsible for tracking
Dispatcher stations. available Resources
A logical component corresponds to a subsystem that has no explicit
run-time equivalent, for example, individual business components that
are composed together into a single run-time application logic layer.

A physical component corresponds to a subsystem that as an explicit

run-time equivalent, for example, a database server.
 Services and Subsystem Interfaces

A service is a set of related operations that share a common

purpose.
A subsystem providing a notification service,
for example,
 defines operations to send notices,
 look up notification channels, and
 subscribe and unsubscribe to a channel.
The set of operations of a subsystem that are available to other
subsystems form the subsystem interface.
COUPLING AND COHESION