UNIT-3_SE_PPT1.pptx software engineering

UNIT-I:
Introduction to Software Engineering: Definition of Software
Engineering, application areas of software engineering, Process
Framework, Process Patterns, Process Assessment, Personal and
Team Process Models, Process Technology, Product and Process.
Process Models: Prescriptive Models, Waterfall Model, Incremental
Process Models, Evolutionary Process Models, Specialized Process
Models, and the Unified Process.
An Agile view of Process: What is Agility. What is an Agile Process,
and Agile Process Models.
UNIT-II:
Understanding requirements: Requirement Analysis, Data Modeling
Concepts, Scenario-Based Modeling, Flow-Oriented Modeling,
Class-Oriented Modeling, Creating a Behavioral Modeling.
Design Engineering: Design within the context of SE, Design Process,
Design Concepts, and the Design Model.

Topics
• Architectural Design: Software Architecture, Architecture
Genres, Architecture Styles, Architectural Design.
• Component level Design: What is a Component, Designing
Class-Based Components, Conducting Component-Level
Design, Component-Based development and Object
Constraint Language.
• Performing User Interface Design: The Golden rules, User
Interface Analysis and Design, Interface Design Steps, and
design Evaluation.

Agenda
• Architectural Design:
Software Architecture,
Architecture Genres,
Architecture Styles,
Architectural Design.

Software Architecture
• What Is Architecture?
- consider the architecture of a building.
- think about the overall shape of the physical structure.
- It is the feel of the structure—the visual impact of the
building.
• what about software architecture?
- is the structure which comprise software components,
the externally visible properties of those components,
and the relationships among them.

• software components:
program module or an object-oriented class,
databases and
“middleware” that enable the configuration of a
network of clients and servers.
• The architecture is not the operational software.
• Rather, it is a representation that enables you to
analyze the effectiveness of the design in meeting its
stated requirements.
• What is the difference between the terms
architecture and design?

• A design is an instance of an architecture similar to an
object being an instance of a class.
• For example, consider the client-server architecture.
• I can design a network-centric software system in
many different ways from this architecture using either
the Java platform (Java EE) or Microsoft platform (.NET
framework).
• So, there is one architecture, but many designs can be
created based on that architecture.
• Therefore, we cannot mix “architecture” and “design”
with each other.
• a software design is an instance of a specific software
architecture.

Why Is Architecture Important?
• There are three key reasons that software architecture is
important:
• Representations of software architecture are an enabler for
communication between all parties (stakeholders)
interested in the development of a computer-based system.
• The architecture highlights early design decisions that will
have a profound impact on all software engineering work
that follows and, as important, on the ultimate success of
the system as an operational entity.
• Architecture “constitutes a relatively small, intellectually
understandable model of how the system is structured and
how its components work together”

Architectural Genre
• In the context of architectural design, genre implies a
specific category within the overall software domain.
• Within each category, we encounter a number of
subcategories.
• For example, within the genre of buildings, you
would encounter the following general styles:
houses, apartment buildings, office buildings,
industrial building, and so on.

Architectural genres for software-based systems:
• Artificial intelligence—Systems that simulate or
enhance human thought, or other organic processes.
• Commercial and nonprofit—Systems that are
fundamental to the operation of a business
enterprise.
• Communications—Systems that provide the
infrastructure for transferring and managing data, for
connecting users of that data, or for presenting data.
• Devices—Systems that interact with the physical
world to provide some point service for an individual.
• Entertainment and sports—Systems that manage
public events or that provide a large group
entertainment experience.

• Financial—Systems that provide the infrastructure for
transferring and managing money and other securities.
• Government—Systems that support the conduct and
operations of a local, state, federal, global, or other
political entity.
• Medical—Systems that diagnose or heal or that contribute
to medical research.
• Operating systems—Systems that sit just above hardware
to provide basic software services.
• Platforms—Systems that sit just above operating systems
to provide advanced services.
• Transportation—Systems that control water, ground, air,
or space vehicles.
• Utilities—Systems that interact with other software to
provide some point service

Architecture Styles
The architectural style is a template for construction.
The intent is to establish a structure for all components of
the system.
The software that is built for computer-based systems also
exhibits one of many architectural styles.
A Brief Taxonomy of Architectural Styles:
• Data-centered architectures.
• Data-flow architectures.
• Call and return architectures.
• Object-oriented architectures.
• Layered architectures.

Data-centered architectures.
Client software accesses
a central repository.
Data can be passed among clients using the blackboard mechanism
(i.e., the blackboard component serves to coordinate the transfer of
information between clients).

Data-flow architectures.
• input data are to be transformed through a series of
computational components(called filters) into output
data.
• filters, connected by pipes that transmit data from one
component to the next.

Call and return architectures.
Remote procedure call architectures. The components of a
main program/subprogram architecture are distributed across
multiple computers on a network.

Object-oriented architectures.
• The components of a system encapsulate data and
the operations that must be applied to manipulate
the data. Communication and coordination between
components are accomplished via message passing.

Layered architectures.
At the outer layer, components service user interface operations.
At the inner layer, components perform operating system
interfacing. Intermediate layers provide utility services and
application software functions.
A number of
different layers are
defined, each
accomplishing
operations

Architectural Design
• At the architectural design level, a software architect uses an
Architectural Context Diagram (ACD).
• ACD represents how the software interacts with entities external
to its boundaries.
as part of some higher-level processing scheme
information is
either produced
or consumed by
the peers and
the target
system
provide data or processing that are necessary
to complete target system functionality
entities (people,
devices) that interact
with the target system
by producing or
consuming information
that is necessary for
requisite processing.
Each of these
external entities
communicates with
the target system
through an interface
(the small shaded
rectangles).

UNIT-3_SE_PPT1.pptx software engineering

Component level Design
• What is a Component?
• Designing Class-Based Components,
• Conducting Component-Level Design,
• Component-Based development and Object
Constraint Language.

What is a Component?
• A component is a modular building block for computer software.
• UML defines a component as “ a modular, deployable, and
replaceable part of a system that encapsulates implementation
and exposes a set of interfaces.”
• The true meaning of the term component will differ depending
on the point of view of the software engineer who uses it.
• There are three important views of what a component is and
how it is used as design modeling.
1. An Object-Oriented View
2. The Traditional View
3. A Process-Related View

• An Object-Oriented
View
• From an object oriented
viewpoint, a component
is a set of collaborating
classes.
• Each class within a
component has been
fully elaborated to
include all attributes and
operations that are
relevant to its
implementation.
Elaboration of a design component

The Traditional View:
a component is a
functional element of
a program that
incorporates
processing logic, the
internal data
structures that are
required to
implement the
processing logic.

The ComputePageCost module accesses data by invoking the module
getJobData, which allows all relevant data to be passed to the component, and
a database interface, accessCostsDB, which enables the module to access a
database that contains all printing costs.
the ComputePageCost
module is elaborated to
provide algorithm detail
and interface detail.
Design elaboration
continues until sufficient
detail is provided to
guide construction of the
component.

• A Process-Related View
• The object-oriented and traditional views of
component-level design assume that the component
is being designed from scratch.
• The process-related view emphasizes building
software from existing components
maintained in a library rather than creating
them from scratch.
• The process view deals with the dynamic
aspects of the system, explains the system
processes and how they communicate, and
focuses on the run time behavior of the
system.

Designing Class-Based Components
• Basic Design Principles
• Component-Level Design Guidelines
• Cohesion - Cohesion is a measure of the degree to which
the elements of a module are functionally related.
• Coupling- Coupling is the measure of the degree of
interdependence between modules.
• If the software is not properly modularized, a host of
enhancement or changes will result into death of the
project.
• Therefore, a software engineer must design the modules
with goal of high cohesion and low coupling.

Designing Class-Based Components
• Basic Design Principles:
• The Open-Closed Principle (OCP):“A module [component]
should be open for extension but closed for modification”

• The Liskov Substitution Principle (LSP). “Subclasses should be
substitutable for their base classes”.
• Proposed by Barbara Liskov, suggests that a component that
uses a base class should continue to function properly if a class
derived from the base class.
• Dependency Inversion Principle (DIP). “Depend on abstractions.
Do not depend on concretions”.
• Abstractions are the place where a design can be extended
without great complication.
• A component depends on other concrete components (rather
than on abstractions such as an interface), the more difficult it
will be to extend.
• The Interface Segregation Principle (ISP). “Many client-specific
interfaces are better than one general purpose interface”

• Component-Level Design Guidelines:
• Components:Naming conventions should be established for
components.
• For example, <<infrastructure>> might be used to identify an
infrastructure component, <<database>> could be used to identify a
database , <<table>> can be used to identify a table within a database
• Interfaces. Interfaces provide important information about
communication and collaboration.
• Dependencies and Inheritance. For improved readability, it is a good
idea to model dependencies from left to right and inheritance from
bottom (derived classes) to top (base classes).
• In addition, component interdependencies should be represented via
interfaces, rather than by representation of a component-to-
component dependency.

• Cohesion is a measure of the degree to which the elements of a
module are functionally related.
• Implies that a component or class encapsulates only attributes
and operations that are closely related to one another and to the
class or component itself.
Types of cohesion
• Functional. Exhibited primarily by operations, this level of
cohesion occurs when a component performs a targeted
computation and then returns a result.
• Communicational. All operations that access the same data are
defined within one class. In general, such classes focus solely on
the data in question, accessing and storing it.

Layer. Exhibited by packages,
components, and classes, this type
of cohesion occurs when a higher
layer accesses the services of a
lower layer, but lower layers do
not access higher layers.
Consider, for example, the
SafeHome security function
requirement to make an outgoing
phone call if an alarm is sensed.
Classes and components that exhibit functional, layer, and
communicational cohesion are relatively easy to implement,
test, and maintain.
Layer cohesion

Coupling
• Coupling is the measure of the degree of interdependence
between modules.
• At analysis and design level , communication and collaboration
are essential elements of any object-oriented system.
• As the amount of communication and collaboration increases
(i.e., as the degree of “connectedness” between classes
increases), the complexity of the system also increases.
• And as complexity increases, the difficulty of implementing,
testing, and maintaining software grows.
• Coupling is a qualitative measure of the degree to which
classes are connected to one another.
• As classes (and components) become more interdependent,
coupling increases.
• An important objective in component-level design is to keep
coupling as low as is possible.

Coupling categories:
• Content coupling. Occurs when one component “secretly
modifies data that is internal to another component”. This
violates information hiding—a basic design concept.
• Common coupling. Occurs when a number of components all
make use of a global variable. common coupling can lead to
uncontrolled error propagation and unexpected side effects
when changes are made.
• Control coupling. Occurs when operation A() invokes operation
B() and passes a control flag to B. The control flag then “directs”
logical flow within B.
• The problem with this form of coupling is that an unrelated
change in B can result in the necessity to change the meaning of
the control flag that A passes. If this is overlooked, an error will
result.

• Stamp coupling. Occurs when ClassB is declared as a type for
an argument of an operation of ClassA. Because ClassB is now
a part of the definition of ClassA, modifying the system
becomes more complex.
• Data coupling. Occurs when operations pass long strings of
data arguments. The “bandwidth” of communication between
classes and components grows and the complexity of the
interface increases. Testing and maintenance are more
difficult.
• Routine call coupling. Occurs when one operation invokes
another. This level of coupling is common and is often quite
necessary. However, it does increase the connectedness of a
system.

• Typeuse coupling. Occurs when component A uses a data type
defined in component B (e.g., this occurs whenever “a class declares
an instance variable or a local variable as having another class for its
type”. If the type definition changes, every component that uses the
definition must also change.
• Inclusion or import coupling. Occurs when component A imports or
includes a package or the content of component B.
• External coupling. Occurs when a component communicates or
collaborates with infrastructure components (e.g., operating system
functions, database capability, telecommunication functions).
Although this type of coupling is necessary, it should be limited to a
small number of components or classes within a system.
Software must communicate internally and externally. Therefore,
coupling is a fact of life. However, the designer should work to reduce
coupling whenever possible.

Topics
• Conducting Component-Level Design
• Component-Based development
• Object Constraint Language.

Conducting Component-Level Design
• We must transform information from requirements and
architectural models into a design representation that
provides sufficient detail to guide the construction (coding
and testing) activity.
• The following steps represent a typical task set for
component-level design, when it is applied for an object-
oriented system.
• Step 1. Identify all design classes that correspond to the
problem domain.
• Step 2. Identify all design classes that correspond to the
infrastructure domain.
• Step 3. Elaborate all design classes that are not acquired as
reusable components.
• Step 3a. Specify message details when classes or components
collaborate.

• Step 3b. Identify appropriate interfaces for each
component.
• Step 3c. Elaborate attributes and define data types and
data structures required to implement them.
• Step 3d. Describe processing flow within each operation
in detail.
• Step 4. Describe persistent data sources (databases and
files) and identify the classes required to manage them.
• Step 5. Develop and elaborate behavioral
representations for a class or component.
• Step 6. Elaborate deployment diagrams to provide
additional implementation detail
• Step 7. Refactor every component-level design
representation and always consider alternatives.

Component-Based development
• Component-based software engineering (CBSE) is a process
that emphasizes the design and construction of computer-
based systems using reusable software “components.”
• Object Constraint Language.
• Object Constraint Language (OCL) is a formal notation.
• This makes the language more friendly to people who are
less mathematically inclined, and more easily processed by
computer.
• To use OCL, need to start with one or more UML diagrams
—most commonly class, state, or activity diagrams .
• OCL expressions are added and state facts about elements
of the diagrams.
• These expressions are called constraints;

Object Constraint Language.
• Like an object-oriented programming language, an OCL
expression involves operators operating on objects. However,
the result of a complete expression must always be a Boolean,
that is, true or false.
• OCL is a modeling language, but it has all of the attributes of a
formal language.
Class diagram for a block handler
block handler

Performing User Interface Design:
• The Golden rules,
• User Interface Analysis and Design,
• Interface Design Steps,
• Design Evaluation.

User Interface Design
• User interface design creates an effective
communication medium between a human and a
computer.
• It is the way through which a user interacts
with an application or a website.
• A software engineer designs the user interface.
User interface is
important to
meet user
expectations and
support the
effective
functionality of
site.

• The Golden rules: There are three golden rules:
1. Place the user in control.
2. Reduce the user’s memory load.
3. Make the interface consistent.
• These golden rules guide the important aspect of
software design.

1.Place the user in control.
• It knows what we want to do before we need to do it
and makes it very easy for us to get it done.
• Several design principles that allow the user to maintain control:
1.Define interaction modes in a way that does not force a
user into unnecessary or undesired actions.
(There is no reason to force the user to remain in spell-checking mode if the
user desires to make a small text edit along the way)
2.Provide for flexible interaction.
(software might allow a user to interact via keyboard commands, mouse
movement, a digitizer pen, a multitouch screen, or voice recognition
commands)

3.Allow user interaction to be interruptible and undoable.
(Even when involved in a sequence of actions, the user should be able to
interrupt the sequence to do something else (without losing the work that
had been done). The user should also be able to “undo” any action)
4.Streamline interaction as skill levels advance and allow the
interaction to be customized.
(customize the interface to facilitate interaction.)
5. Hide technical internals from the casual user.
(The user should not be aware of the operating system, file management
functions)
6.Design for direct interaction with objects that appear on the
screen.
(user feels a sense of control when able to manipulate the objects that are
necessary to perform a task)

2. Reduce the user’s memory load.
• The more a user must remember, the more error-
prone the interaction with the system will be.
• So, for this reason a well-designed user interface
does not tax the user’s memory.
• Whenever possible, the system should “remember”
relevant information and assist the user with an
interaction scenario that assists recall.

Design principles that enable an interface to reduce the user’s
memory load:
• Reduce demand on short-term memory.
(The interface should be designed to reduce the requirement to remember
past actions, inputs, and results.)
• Establish meaningful defaults.
(The initial set of defaults should make sense for the average user, but a user
should be able to specify individual preferences.)
• Define shortcuts that are intuitive.
(e.g., alt-P to invoke the print function i.e. first letter of the task to be invoked)
• The visual layout of the interface should be based on a real-world
metaphor.
(For example, a bill payment system should use a checkbook and check
register metaphor to guide the user through the bill paying process.)

3.Make the interface consistent.
• a set of design principles that help make the interface consistent
• Allow the user to put the current task into a meaningful
context.
(It is important to provide indicators (e.g., window titles, graphical icons,
consistent color coding) that enable the user to know the context of the work at
hand. )
• Maintain consistency across a family of applications.
(A set of applications (or products) should all implement the same design rules so
that consistency is maintained for all interaction.)
• If past interactive models have created user expectations, do
not make changes unless there is a compelling reason to do
so.
(Once a particular interactive sequence has become a de facto standard (e.g., the
use of alt-S to save a file), the user expects this in every application he
encounters. A change (e.g., using alt-S to invoke scaling) will cause confusion)

User Interface Analysis and Design
• The overall process for analyzing and designing a user
interface begins with the creation of different models of
system function.
• Interface Analysis and Design Models:
• A human engineer (or the software engineer) establishes
a user model,
• the software engineer creates a design model,
• the end user develops a mental image that is often called
the user’s mental model or the system perception, and
• the implementers of the system create an
implementation model.

The Process
• The analysis and design process for user interfaces is iterative and can be
represented using a spiral model.
• The user interface analysis and design process begins at the interior of the
spiral and encompasses four distinct framework activities:
(1) interface analysis and modeling,
(2) interface design,
(3) interface construction,
(4) interface validation.
focuses on the profile of the
users who will interact with
the System,
requirements are elicited, a
more detailed task analysis is
conducted.
Analysis of the user
environment focuses on the
physical work environment
define a set of
interface objects
and actions
begins with the creation of
a prototype that enables
usage scenarios to be
evaluated.
focuses on (1) implement
every user task correctly
(2) easy to use and easy to
learn,
(3) the users’ acceptance as a
useful tool in their work.
Fig. The user interface design process

Interface design steps
• Once interface analysis has been completed, all tasks (or
objects and actions) required by the end user have been
identified in detail and the interface design activity
commences.
• Interface design, like all software engineering design, is
an iterative process.
Steps:
1. Using information developed during interface analysis,
define interface objects and actions (operations).
2. Define events (user actions) that will cause the state of
the user interface to change. Model this behaviour.
3. Depict each interface state as it will look to the end user.
4. Indicate how the user interprets the state of the system
from information provided through the interface.

Design Evaluation
• Once you create an operational user
interface prototype, it must be evaluated to
determine whether it meets the needs of the
user.
• After the design model has been completed,
a first-level prototype is created.
• The prototype is evaluated by the user, who
provides you with direct comments about
the efficacy of the interface.
• Design modifications are made based on
user input, and the next level prototype is
created.
• The evaluation cycle continues until no

• Once the first prototype is built, we can collect a variety of
qualitative and quantitative data that will assist in evaluating the
interface.
• To collect qualitative data, questionnaires can be distributed to
users of the prototype. Questions can be:
(1)simple yes/no response,
(2)numeric response,
(3)scaled (subjective) response,
(4)Likert scales (e.g., strongly agree, somewhat agree),
(5)percentage (subjective) response,
(6)open-ended.
• If quantitative data are desired, a form of time-study analysis can
be conducted. Users are observed during interaction, and data—
such as
• number of tasks correctly completed over a standard time period,
• frequency of actions, sequence of actions,
• time spent “looking” at the display,
• number and types of errors, error recovery time,
• time spent using help, and number of help references per standard

Summary
• Architectural Design: Software Architecture,
Architecture Genres, Architecture Styles,
Architectural Design.
• Component level Design: What is a Component,
Designing Class-Based Components, Conducting
Component-Level Design, Component-Based
development and Object Constraint Language.
• Performing User Interface Design: The Golden rules,
User Interface Analysis and Design, Interface Design
Steps, and design Evaluation.

UNIT-3_SE_PPT1.pptx software engineering

More Related Content

Similar to UNIT-3_SE_PPT1.pptx software engineering (20)

More from David Raju N (7)

Recently uploaded (20)

UNIT-3_SE_PPT1.pptx software engineering