Software Engineering

Activity # 8 & 9 cover by students

System Models / Analysis Modeling and
system design
System model
 Activity # 8
 Structured Modeling
 Data modeling
 Object Oriented Modeling
 Scenario Based Modeling
 Class oriented Modeling
 Behavioral Modeling

2
Objectives
 To establish a basis for the creation of a software design.
 To devise a set of requirements that can be validated once the
software is built.
 To describe behavioural modelling, data modelling and object
modelling
 To introduce some of the notations used in the Unified
Modelling Language (UML)

3
Introduction
 User requirements must be written in natural languages
because they have to be understood by people who are
not technical experts.
 However, more detailed system requirements may be
expressed in a more technical way.
 One widely used technique is to document the system
specification as a set of system models.
 Because system models have graphical representations,
they are more understandable than detailed natural
descriptions of the system requirements.
4
Requirements Analysis
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other system elements
 establishes constraints that software must meet

 Requirements analysis allows the software engineer (called

an analyst or modeler in this role) to:
 elaborate on basic requirements established during earlier
requirement engineering tasks
 build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class behavior,
and the flow of data as it is transformed.

5
System Modelling
 Abstract descriptions of systems whose requirements are being
analysed
 One way to structure unstructured problems is to draw models.
 A model is a simplification/representation of reality. Just as a

picture is worth a thousand words, most system models are

pictorial representations of reality.
 A model may provide
 blueprints of a system
 Organization of the system
 Dynamic of the system
 Models can be built for existing systems as a way to better
understand those systems, or for proposed systems
6
Why We Model
 “A successful software organization is one that consistently
deploys quality software that meets the needs of its users.
 Model is built to:-
 Communicate the desired structure and behavior of the system
 Visualize and control the system’s architecture
 Better understand the system that being built
 Manage risk
 Expose opportunities for simplification and reuse
 We build models so that we can see and better understand
the system we are developing.

7
Principles of Modeling
 Choose your model well - the choice of model profoundly
impacts the analysis of the problem and the design of the
solution.
 Every model may be expressed at different levels of precision -
the same model can be scaled up (or down) to different
granularities.
 The best models are connected to reality - simplify the model,
but don’t hide important details.
 No single model suffices - every nontrivial system has
different dimensions to the problem and its solution.
8
Analysis Modeling Approaches
 Structural analysis:
 The data: The model defines their attributes and
relationships.
 Modeling data by using entity relation ship diagram(ERD).
 The processes that transform the data: The model shows
how they transform the data objects as they flow through
the system.
 Data flow and transformations are modeled by using data flow
Diagram(DFD)
 Object-oriented analysis:
 Focus: Classes and their inter-relationships
 UML is predominantly object-oriented
9
Elements of the Analysis Model
Object-oriented Analysis Structured Analysis

Scenario-based Flow-oriented
modeling modeling

Use case diagrams Data Modeling(ERD)

Data processing

Class-based Behavioral
modeling modeling
Class diagrams Sequence diagrams
Analysis packages Activity diagrams
CRC models State diagrams
Collaboration diagrams
10
Structured Analysis Modeling

Data Modeling
 Describes relationships between data objects
 Graphically represented by ERD, which contains the following
items
 Data objects (Entities)- anything that produces or consumes
information
 Data attributes- define properties of entities
 Relationships- associations between instances of one or more
entity types that is of interest
 Cardinality :-(number of occurrences)

11
ER model can be represented as the following

12
example ERD:- online shopping system

name Id
Price

Id
Customer
buys Product

model

does

Payment

13
Data processing models / Functional modeling

 Data processing, flow and transformation of data are modeled

by using data flow diagram
 Show end-to-end processing of data.
 Data flow diagram
 Depicts how input is transformed into output as data objects

move through a system

 Model the system from functional perspective

 Tracking and documenting how the data associated with a

process.
 Used in showing the data exchange between a system and

other systems in its environment

14
Data flow Diagram is depicted as follows;

15
First level (DFD)Diagram : online shopping systems

16
Second level DFD diagram

17
Data Dictionary
 Data dictionaries are lists of all of the names used in
the system models. Descriptions of the entities,
relationships and attributes are also included.
 Advantages
 Support name management and avoid duplication;
 Store of organisational knowledge linking analysis, design
and implementation;
 Stores information of users or entities

18
Example: Table,Tbl_ User
Description: -This table store information of User like Name, Address,
password and Email Address.

Field Name Data Type Description Allow Null

ID Varchar(50) User name Primary key

Pass Varchar(50) password Not null

Add Varchar(50) address Not null
Emal Varchar(50) Email address Not null

19
Object Oriented Modeling
 Object-oriented modeling: is an approach to modeling
an application that is used at the beginning of the
software life cycle when using an object-oriented
approach to software development.
 The most common language used to do object-oriented

modeling is the Unified Modeling Language(UML)

20
 Object oriented modeling
 Centers around objects and classes
 Involves inheritance
 Encapsulates both data and behavior
 Benefits of Object-Oriented Modeling:-
 Ability to tackle challenging problems
 Improved communication between users, analysts, designers,
and programmers
 Increased consistency in analysis, design, and programming
 Explicit representation of commonality among system
components
 System robustness
 Reusability of analysis, design, and programming results

21
Unified Modelling Language

 The UML is a general-purpose modeling language in the field

of software engineering, which is designed to provide a
standard way to visualize the design of a system.
 It is a graphical language for specifying, visualizing,
constructing, documenting the artifacts of software systems
 It has become an effective standard for object-oriented
modelling.

22
UML diagrams

23
UML diagrams…
Structural diagrams –
 Used to describe the building blocks of the system – features

that do not change with time.

 Structural Diagrams – focus on static aspects of the software system
 These diagrams answer the question – What's there?
--- Class, Object, Component, Deployment
Behavioral diagrams –
 Used to show how the system evolves over time (responds

to requests, events, etc.)

 focus on dynamic aspects of the software system
--- Use-case, sequence, State Chart, Activity
24
Class diagram
 Used for object modelling
 Object models describe the system in terms of object classes and
their associations.
 An object class is an abstraction over a set of objects with common
attributes and the services (operations) provided by each object.
 It shows the classes in a system, attributes 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.
25
Class diagram
 ..

26
 In large systems with many related classes, classes are
grouped together to create class diagrams.
 Different relationships between classes are shown by different
types of arrows.
 Various object models may be produced
 Inheritance models
 Aggregation models
 Interaction models

27
Inheritance models
 Organise the domain object classes into a hierarchy.
 Classes at the top of the hierarchy reflect the common
features of all classes.
 Object classes inherit their attributes and services from
one or more super-classes - these may then be specialised
as necessary.
 Class hierarchy design can be a difficult process if
duplication in different branches is to be avoided.
 Class diagrams - describe classes and their relationships

28
Library class hierarchy

29
User class hierarchy

30
Multiple inheritance

 Rather than inheriting the attributes and services from a

single parent class, a system which supports multiple
inheritance allows object classes to inherit from several
super-classes.
 This can lead to semantic conflicts where
attributes/services with the same name in different super-
classes have different semantics.
 Multiple inheritance makes class hierarchy reorganisation
more complex.

31
Multiple inheritance

Book Voice recording

Author Speaker
Edition Duration
Publication date Recording da
te
ISBN

Talking book

# a
Tpes

32
Object aggregation

 An aggregation model shows how classes that are

collections are composed of other classes.
 Aggregation models are similar to the part-of relationship
in semantic data models.
 The UML notation for aggregation is to represent the
composition by including a diamond shape on the source
of the link.

33
Object aggregation representing a course

34
Object behaviour modelling
(Interaction models )
 A behavioural model shows the interactions between
objects to produce some particular system behaviour
that is specified as a use-case.
 In the UML, behaviours are modelled using scenarios

which are based on use-case

 Sequence diagrams (or collaboration diagrams) in the

UML are used to model interaction between objects.

35
Use Case Diagrams
 use case diagram is “a diagram that shows the relationships
among actors and use cases within a system.”
 Describes a set of sequences.
 Each sequence represents the interactions of things outside the
system (actors) with the system itself (and key abstractions)
 Use cases represent the functional requirements of the system
 Use case diagram consist of use cases, actors and relationships
among actors and use cases

36
 A set of ACTORS : roles users can play in interacting
with the system.
 An actor is used to represent something that users our system.
 A set of USE CASES: each describes a possible kind of
interaction between an actor and the system.
 Uses cases are actions that a user takes on a system
 A number of RELATIONSHIPS between these entities
(Actors and Use Cases).
 Relationships are simply illustrated with a line connecting
actors to use cases.

37
Use case
 A use case is a sequence of actions performed by an actor and
the system that yields an observable result, or set of results, of
value for one or more actors.

 Each use case has a descriptive name

 Describes what a system does but not how it does it.
 Use case names must be unique within a given package
 Examples: withdraw money, process loan

use case

38
Actor

An actor represents one of the following things:

 A role that a user can play with regard to a system.

 An entity, such as another system or a database, that resides

outside the system.

 Actors have a name

 An actor is a set of roles that users of use cases play when

interacting with the system

 They are external entities

 They may be external an system or DB

 Examples: Customer, Loan officer

39
Course Registration system Use case Diagram

Register in Course
Add Course Offering

Registrar Actor Add Course

Enter Grade
for Course
Student

Find information about course

Professor Actor
40
Use Case Diagrams - Relationships
 Inclusion <<includes>>
 Within an include relationship, one use case explicitly includes the
behavior of another use case at a specified point within a course of
action.
 Allow one to express commonality between several different use
cases.
 Add to wish list include login

41
 Extension <<extends>>
 Allows creating a new use case by adding steps to existing use
cases

42
 Generalization
 Allows child use cases to inherit behavior from parent use cases
 Much like super classes in a class diagram.
 The following use case describe three different searches that a
Customer can perform, all of which use the basic search
technique defined by the Perform Search use case.

43
Example of use case diagram
Actor Web store
(person)
Free search

Find an
item
Structured
search
Customer
<<include>>

Order an <<extend>> Order fast Actor

item delivery (system)

SADAD
Check
order relatio
Registered nship
use case
customer
44
How to describe a single use case
Name: Give a short, descriptive name to the use case.
Actors: List the actors who can perform this use case.
Goals: Explain what the actor or actors are trying to achieve.
Preconditions: State of the system before the use case.
Summary: Give a short informal description.
Related use cases.
Steps: Describe each step using a 2-column format.
Post conditions: State of the system in following completion.

Name and steps are the most important

45
Use Case example

46
Example: description of a use case
Use case: Open file

Related use cases:

Generalization of:
• Open file by typing name
• Open file by browsing

Steps:
Actor actions System responses
1. Choose ‘Open…’ 2. File open dialog
command appears
3. Specify filename
4. Confirm selection 5. Dialog disappears

47
Example…
Use case: Open file by typing name

Related use cases:

Specialization of: Open file

Steps:
Actor actions System responses
1. Choose ‘Open…’ 2. File open dialog
command appears
3a. Select text field
3b. Type file name
4. Click ‘Open’ 5. Dialog disappears
48
Example…
Use case: Open file by browsing

Related use cases:

Specialization of: Open file
Includes: Browse for file

Steps:
Actor actions System responses
1. Choose ‘Open…’ 2. File open dialog
command appears
3. Browse for file
4. Confirm selection 5. Dialog disappears
49
Example…
Use case: Attempt to open file that does not exist

Related use cases:

Extension of: Open file by typing name

Actor actions System responses

1. Choose ‘Open…’ 2. File open dialog
command appears
3a. Select text field
3b. Type file name
4. Click ‘Open’ 5. System indicates that
file does not exist
6. Correct the file name
7. Click ‘Open’ 8 Dialog disappears 50
Example…
Use case: Browse for file (inclusion)

Steps:
Actor actions System responses
1. If the desired file is not 2. Contents of
displayed, select a directory directory is displayed
3. Repeat step 1 until the
desired file is displayed
4. Select a file

51
Activity diagram
 UML activity diagram supplements the use case by providing
a graphical representation of the flow of interaction within a
specific scenario.
 Activity diagrams model the workflow of a business process
and the sequence of activities in a process.
 These diagrams are very similar to a flowchart because you
can model a workflow from activity to activity or from
activity to state
 Activity diagrams typically are used to illustrate the
following:
--The flow of a complicated use case.
--A workflow across use cases.
--The logic of an algorithm. 52
Activity Diagram Cont…..
 Activity diagrams have activity nodes and activity edges
 activity nodes, which are placeholders for one or more

steps within an activity.

 activity edges, which are connections between activity

nodes.
 Activity nodes has different control nodes
 Control nodes coordinate flows among other activity

nodes
 Different Control nodes are described below;
 An initial node is where the flow of control starts when

an activity is invoked.
53
54
A decision node appears as a diamond, as shown in diagram
below

• A merge node brings together multiple alternate control

flows.

55
 A fork node splits a flow into multiple concurrent
flows.

• A join node synchronizes multiple control flows.

56
 Generally, controls or data must be available on every
incoming edge in order to be passed to the outgoing
edge, but user can specify different conditions under
which a join accepts incoming controls and data using a
join specification.

57
Activity diagram for creating shipment

58
59
State chart Diagrams
 State chart diagram is used to describe the states of different
objects in its life cycle. So the emphasis is given on the state
changes upon some internal or external events.
 Following are the main purposes of using State chart
diagrams:
 To model dynamic aspect of a system.
 To model life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model states of an object.

60
 Before drawing a Statechart diagram we must have clarified
the following points:
 Identify important objects to be analyzed.
 Identify the states.
 Identify the events.
 The following is an example of a Statechart diagram where the
state of Order object is analyzed.
 The first state is an idle state from where the process starts.
 The next states are arrived for events like send request,
confirm request, and dispatch order. These events are
responsible for state changes of order object.

61
62
Sequence diagrams
 A sequence diagram illustrates object interactions
arranged in a time sequence
 These diagrams are typically associated with use cases.
 Sequence diagrams show you step by step what has to
happen to accomplish something in the use case
 This type of diagram emphasizes the sequence of
events, whereas collaboration diagrams(an alternative
view of the information) emphasizes the relationship
 A sequence diagram focuses on the time-ordering of
messages between objects, that is to say, displays the
time sequence of the objects participating in the
interaction. 63
First, we will see a fun example, in which four objects
participate.

64
 These four objects participate in an interaction in the
following way:
-- the person kicks the cat,
--the cat reports to the inspector what the person did to
him,
--the inspector reports to the policeman what the person
did to the cat,
--the policeman arrests the person.

65
66
Account Login sequence diagram

67
 Sequence diagrams are excellent vehicles
for workingyour way through use cases and
allocating the required behavior to the participating
objects.

 Sequence diagrams and communication diagrams

are semantically equivalent, which means you can
convert one type of diagram to the other without
losing any information.
 However, a sequence diagram has two key features
that a communication diagram does not: lifelines
and focuses of control.

68
Communication (Collaboration) Diagrams

 A communication diagram focuses on the interaction

between lifelines, where the architecture of the internal
structure and how this corresponds with the message
passing is central.
 The messages are usually notated with sequence
numbers, which indicate the relative execution order of
the associated messages.

69
70
Login system collaboration diagram

71
 Communication diagrams and sequence diagrams
are semantically equivalent, which means that you
can convert one type of diagram to the other without
losing any information.

 A sequence diagram does not have sequence

numbers, but it has a number of features that
communication diagrams do not offer.
 Since both sequence diagrams and communication
diagrams are done at the design level, it makes
sense to put them into design-level packages

72
CASE workbenches
 A coherent set of tools that is designed to
support related software process activities such
as analysis, design or testing.

 Analysis and design workbenches support

system modelling during both requirements
engineering and system design.

 These workbenches may support a specific

design method or may provide support for a
creating several different types of system model.
73
An analysis and design workbench

74
Summary
 A model is an abstract system view.
Complementary types of model provide different
system information.
 Context models show the position of a system in
its environment with other systems and
processes.
 Data flow models may be used to model the
data processing in a system.
 State machine models model the system’s
behaviour in response to internal or external
events
75
Summary
 Data models describe the logical structure of
data which is imported to or exported by the
systems.
 Object models describe logical system entities,
their classification and aggregation.
 Sequence models show the interactions
between actors and the system objects that they
use.
 Structured methods provide a framework for
developing system models.
76
………………………………..
 …………………………………………

Any ?
77
Software Engineering
Activity #9
Software Design
• Data Design
• Architectural Design
• Interface Design
• Component Design
Objectives
 To explain importance of software design
 To understand different design models and their

importance
 To introduce architectural design and to discuss

its importance
 To suggest some general design principles for

user interface design

79
Software Design
 Requirements specification was about the WHAT the
system will do.
 Design is about the HOW the system will perform its
functions.
 It is also a technical description about how the system
will implement the requirements
 System Design
 Reduces the gap between requirements and the (virtual)
machine
 Decomposes the overall system into manageable parts

80
Cont’d
 Software design encompasses the set of
principles, concepts, and practices that lead to the
development of a high quality system or product
 Goal of software design is to produce a model or
representation that is bug free (firmness), suitable
for its intended uses (commodity), and
pleasurable to use (delight)
 The design model provides detail about software
data structures, architecture, interfaces, and
components that are necessary to implement the
system.
81
Design models
 Software design model consists of 4 designs:
 Data/class Design.. From analyses to class and data structure
 Architectural Design..r/s b/n structural element
 Interface Design..how the s/w ,h/w and end user communicate
 Component Design…. transforming the structural element into
a procedural description of the software components

 Data/Class design - created by transforming the analysis

model class-based elements into classes and data structures
required to implement the software
 Architectural design - defines the relationships among the
major structural elements of the software, it is derived from
the class-based elements and flow-oriented elements of the
analysis model 82
Cont’d
 Interface design - describes how the software elements,
hardware elements, and end-users communicate with one
another, it is derived from the analysis model scenario-
based elements, flow-oriented elements, and behavioral
elements
 Component-level design - created by transforming the
structural elements defined by the software architecture
into a procedural description of the software components
using information obtained form the analysis model class-
based elements, flow-oriented elements, and behavioral
elements
83
Translating the analysis model into a software
design

Component -
sc enario- based f low- oriented L evel Design
elements elements
use-cases - text data flow diagrams
use-case diagrams control-flow diagrams
activity diagrams processing narratives
swim lane diagrams
Int erfac e Design
Analysis Model

A rc hit ec t ural Design

c lass- based behavioral
elements elements
class diagrams state diagrams
analysis packages sequence diagrams
CRC models Dat a/ Class Design
collaboration diagrams

Design Model

84
Why design is so important?
 It is place where quality is fostered.
 It provides us with representation of software that can be
assessed for quality.
 Only way that can accurately translate a customer’s
requirements into a finished software product.
 It serves as foundation for all software engineering
activities.
 Without design difficult to assess:
 Risk
 Test
 Quality

85
Levels of Design
 Architectural design (also: high-level design)
 architecture - the overall structure: main modules and their
connections
 design that covers the main use-cases of the system
 addresses the main non-functional requirements (e.g.,
throughput, reliability)
 hard to change
 Detailed design (also: low-level design)
 the inner structure of the main modules
 may take the target programming language into account
 detailed enough to be implemented in the programming
language
86
Challenges in Design
 Complexity
 Often arbitrary, dependent on designer rather than problem
(“accidental complexity”)
 Conformity
 Often expected to conform to other software (e.g., legacy,
standards)
 Changeability
 Needs to support change due changing requirements,
constraints, etc.
 Invisibility
 No visible link from between design plans and product

87
Design and Software Quality
 S/w design is an iterative process through which
requirements are translated into a “blueprint” for
constructing the s/w.
 Quality
 Design is the place where quality is fostered in software
engineering.
 Design provides us with representation of software that can
be assessed for quality.
 Design is the only way we can translate customers
requirements into finished software product or system.
 Software design serves as the foundation for all the
software engineering and software support steps.
88
Characteristics of a Good Design
 The design must implement all of the explicit
requirements contained in the analysis model, and it
must accommodate all of the implicit requirements
desired by the customer.
 The design must be readable, understandable guide for
those who generate code and for those who test and
support the software.
 The design should provide a complete picture of the
software, addressing the data, functional and
behavioral domains from an implementation
perspective.
89
General Design Guidelines
 A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design
characteristics and
(3) can be implemented in an evolutionary fashion
For smaller systems, design can sometimes be developed linearly.
 A design should be modular; that is, the software should be
logically partitioned into elements or subsystems
 A design should contain distinct representations of data,
architecture, interfaces, and components.
 A design should lead to data structures that are appropriate for
the classes to be implemented and are drawn from recognizable
data patterns.
90
Cont’d
 A design should lead to components that exhibit
independent functional characteristics.
 A design should lead to interfaces that reduce the
complexity of connections between components and
with the external environment.
 A design should be derived using a repeatable method
that is driven by information obtained during software
requirements analysis.
 A design should be represented using a notation that
effectively communicates its meaning.

91
Design Concepts/Fundamentals
 The design should be based on requirements specification.
 The design should be documented (so that it supports
implementation, verification, and maintenance.)
 The design should use abstraction (to reduce complexity and to
hide unnecessary detail.)
 The design should be modular (to support abstraction,
verification, maintenance, and division of labor.)
 The design should be assessed for quality as it is being created,
not after the fact.
 Design should produce modules that exhibit independent
functional characteristics.
 Design should support verification and maintenance.
92
Design Concepts….
 Design concepts provide the necessary framework
for “to get the thing on right way”.
 Abstraction
 Refinement
 Modularity
 Architecture
 Control Hierarchy
 Functional Independence
 Refactoring
 Structural Partitioning
 Data Structure
 Software Procedure
 Information Hiding

93
Abstraction
 Concentrate on problem at some level of
generalization without considering irrelevant details
 Allows working with concepts/terms familiar in the
problem environment
 Is one of the fundamental ways that can be used
to cope with complexity.

94
Modular Design
 Easier to build, easier to change ,easier to fix
 Architecture and design pattern embody modularity.
 Software is divided into separately named and
addressable components, sometimes called
modules, which are integrated to satisfy problem
requirement.
 modularity is the single attribute of software that
allows a program to be intellectually manageable
 It leads to a “divide and conquer” strategy. – it is
easier to solve a complex problem when you break
into a manageable pieces. 95
 Refer fig. that state that effort (cost) to develop
an individual software module does decrease if
total number of modules increase.
 However as the no. of modules grows, the effort
(cost) associated with integrating the modules
also grows.

Mo s t
Co
du
lar
ity
&S
of t
wa
re
96
 Undermodularity and overmodularity should be
avoided. But how do we know the vicinity of M?
 We modularize a design so that development
can be more easily planned.
 Software increments can be defined and
delivered.
 Changes can be more easily accommodated.
 Testing and debugging can be conducted more
efficiently and long-term maintained can be
conducted without serious side effects.

97
Architecture
 Software architecture suggest “ the overall structure of
the software and the ways in which that structure
provides conceptual integrity for a system.
 Number of different models can use to represent
architecture.
 Structural Model- represent architecture as an organized
collection of components
 Framework model – Increase level of design abstraction
by identifying repeatable architectural design framework.
 Dynamic model – address behavior of the program
architecture and indicating how system or structure
configuration may change as a function.
 Process Model – focus on design of the business or
technical process that the system must accommodate.
 Functional models – used to represent the functional 98

hierarchy of a system.
Functional independence
 Functional independence is achieved by developing
modules with "single-minded“ function and an "aversion"
to excessive interaction with other modules.
 In other words - each module addresses a specific sub-
function of requirements and has a simple interface when
viewed from other parts of the program structure.
 Independence is important –
 Easier to develop
 Easier to Test and maintain
 Error propagation is reduced
 Reusable module.
 To summarize, functional independence is a key to good
design, and design is the key to software quality.
99
 To measure independence, have two qualitative criteria:
 cohesion and
 coupling
 Cohesion :-is a measure of the relative functional strength of a
module.
 High cohesion: The classes in the subsystem perform
similar tasks and are related to each other (via
associations)
 Low cohesion: Lots of miscellaneous and auxiliary classes,
no associations
 Coupling :-is a measure of the relative interdependence among
modules.
 High coupling: Changes to one subsystem will have high

impact on the other subsystem (change of model, massive

recompilation, etc.)
 Low coupling: A change in one subsystem does not affect

any other subsystem

 Subsystems should have as maximum cohesion and minimum 100

coupling as possible:
Cohesion
 Cohesion is a natural extension of the information
hiding concept
 A cohesive module performs a single task within a
software procedure, requiring little interaction with
procedures being performed in other parts of a
program
 Simply state, a cohesive module should (ideally) do
just one thing.
 We always strive for high cohesion, although the mid-
range of the spectrum is often acceptable.
 Low-end cohesiveness is much "worse" than middle
range, which is nearly as "good" as high-end cohesion.
 So. designer should avoid low levels of cohesion when
modules are designed.
101
Coupling
 Coupling depends on the interface complexity between
modules, the point at which entry or reference is made to a
module, and what data pass across the interface
 In software design, we strive for lowest possible coupling.
Simple connectivity among modules results in software that
is easier to understand and less prone to a "ripple effect"
caused when errors occur at one location and propagate
through a system.
 It occur because of design decisions made when structure
was developed.
 Coupling is characterized by passage of control between
modules.
 “Control flag” (a variable that controls decisions in a
subordinate or superordinate module) is passed between
modules d and e (called control coupling).
102
 Relatively high levels of coupling occur when
modules are communicate with external to software.
 External coupling is essential, but should be limited

to a small number of modules with a structure.

 High coupling also occurs when a number of modules

reference a global data area.

 Common coupling, no. of modules access a data item

in a global data area

 So it does not mean “use of global data is bad”. It

does mean that a software designer must be take care

of this thing.
103
Control Hierarchy/Program Structure
 Organization of modules that implies a hierarchy of control
 Depth, width, fan-out, fan-in
 Tree like control diagram

Manager

Module A Module B Module C

Module D Module E Module K Module L Module M

Module F Module G Module H Module N Module O Module P Module Q

Module I Module J Module R

104
Data Structure
 Data structure is a representation of the logical
relationship among individual elements of data
 A scalar item is the simplest of all data structures. It
represents a single element of information that may be
addressed by an identifier.
 When scalar items are organized as a list or contiguous
group, a sequential vector is formed.
 When the sequential vector is extended to two, three, and
ultimately, an arbitrary number of dimensions, an n-
dimensional space is created. Most common n-
dimensional space is the two-dimensional matrix

105
 A linked list is a data structure that organizes contiguous
scalar items, vectors, or spaces in a manner (called nodes)
that enables them to be processed as a list.
 A hierarchical data structure is implemented using
multilinked lists that contain scalar items, vectors, and
possibly, n-dimensional spaces.

Software Procedure
 Software procedure focuses on the processing details
of each module individually.
 Procedure must provide a precise specification of
processing, including sequence of events, exact
decision points, repetitive operations, and even data
organization and structure.
106
Information hiding
 The principle of information hiding suggests that modules be
"characterized by design decisions that (each) hides from all
others modules.“
 In other words, modules should be specified and designed so
that information (algorithm and data) contained within a module
is inaccessible to other modules that have no need for such
information.
 The intent of information hiding is to hide the details of data
structure and procedural processing behind a module interface.
 It gives benefits when modifications are required during testing
and maintenance because data and procedure are hiding from
other parts of software, unintentional errors introduced during
modification are less.

107
Refinement
 Successively decomposing or refining specifications in
stepwise fashion
 Development of a program by successively refining levels
of procedure detail
 Complements abstraction, which enables a designer to
specify procedure and data and yet suppress low-level
details
 Refinement is actually a process of elaboration.
 begin with a statement of function (or description of
information) that is defined at a high level of abstraction.
 That is, the statement describes function or information
conceptually but provides no information about the
internal workings of the function or the internal structure
of the information. 108
Refactoring
 A reorganization technique that simplifies the design (or
internal code structure) of a component without changing its
function or external behaviour.
• "Refactoring is the process of changing a software system in
such a way that it does not alter the external behavior of the
code [design] yet improves its internal structure.”
 When software is refactored, the existing design is
examined for
 redundancy
 unused design elements
 inefficient or unnecessary algorithms
 poorly constructed or inappropriate data structures
 or any other design failure that can be corrected to yield a better
design.
109
Structural partitioning
 Horizontal partitioning (division of functionality):
separate branches of control hierarchy
 Vertical partitioning (factoring): distributing work to
“worker” modules

110
Design Elements
 A system is a logical entity, having a set of definable
responsibilities or objectives, and consisting of hardware,
software or both.
 A subsystem is a system that is part of a larger system, and
which has a definite interface.
 A component is any piece of software or hardware that has a
clear role.
 A component can be isolated, allowing you to replace it with

a different component that has equivalent functionality.

 A module is a component that is defined at the programming
language level
 For example, methods, classes and packages are modules in

Java. 111
Design Goals
 Overall goals of good design:
 Increasing profit by reducing cost and increasing revenue
 Ensuring that we actually conform with the requirements
 Accelerating development
 Increasing qualities such as
 Usability
 Efficiency
 Reliability
 Maintainability
 Reusability

112
1. Data Design
 High level model depicting user's view of the data or
information
 Designing the algorithms for the individual parts
 Design of data structures and operators is essential to
creation of high-quality applications
 Translation of data model into database is critical to
achieving system business objectives
 Data design transforms the information domain
model created during analysis into the data structures
that will be required to implement the software.
113
 The data objects and relationships defined in ERD and
the detailed data content depicted in the data
dictionary provide the basis for the data design
activities.

 Data Specification Principles

• Identify all data structures and associated operations
• Establish a data dictionary to define data & program
design
• Representation of data structure should only be known
to modules with direct use of data within the structure
• Develop a library of useful data structures
• Language should support abstract data types

114
Architectural Design
 Designing the structure of the system
 Objective is to develop a modular program structure and
represent the control relationships between modules
 Derived from the system specification, the analysis
model, and the interaction of subsystems defined within
the analysis model.
 Usually depicted as a set of interconnected systems that
are often derived from the analysis packages
 Software architecture is process of designing the global
organization of a software system, including:
 Dividing software into subsystems.
 Deciding how these will interact.
 Determining their interfaces. 115
Cont’d
 The architecture is the core of the design, so all
software engineers need to understand it.
 The architecture will often constrain the overall
efficiency, reusability and maintainability of the
system.
 Once interactions between the system and its
environment have been understood, you use this
information for designing the system architecture.
 You identify the major components that make up the
system and their interactions, and then may organize
the components using an architectural pattern such as
a layered or client-server model.
116
The importance of software architecture

 Why you need to develop an architectural model:

 To enable everyone to better understand the system
 To allow people to work on individual pieces of the system in
isolation
 To prepare for extension of the system
 To facilitate reuse and reusability

Developing an architectural model

 Start by sketching an outline of the architecture

 Based on the principal requirements and use cases
 Determine the main components that will be needed
 Choose among the various “architectural patterns” 117
Describing an architecture using
UML
 All UML diagrams can be useful to describe aspects
of the architectural model
 Four UML diagrams are particularly suitable for

architectural modeling:
 Package diagrams
 Subsystem diagrams
 Component diagrams
 Deployment diagrams

118
Package diagrams

 shows structure of the designed system at the level of

packages.
 A package is a grouping of pieces of a model.
 Packages are very useful in managing models.
They're also quite helpful in grouping related items,
such as use cases, in order to make it easier to break
up work among subteams.

119
• The name of the package appears within the tab, and the
contents of the package are listed in the body of the order package
tab

120
 Example: Package Diagram for ATM System
 Each of these classes, in turn, depends on the package
atm which contains the class ATM that represents the
system as a whole, and the class Session that represents
one session. ATM depends on Session, and vice versa -
since the ATM creates Sessions, and each Session, in
turn, uses the ATM to interact with the customer.
 This package diagram shows how the various classes
are grouped into packages. There are two "top-level"
classes - ATMMain and ATMApplet - which allow the
system to be run (respectively) as an application.

121
 The subpackage transaction contains the classes used
to represent individual transactions that a customer
initiates. The class Session depends on the transaction
package because it creates individual transaction
objects. These, in turn, again depend on the ATM to
interact with the customer.
 The subpackage physical contains the classes that
represent the various physical components of the ATM
 Finally, the package banking contains classes that
represent the banking enterprise itself and the
information communicated back and forth between the
ATM and the bank - i.e. classes which might be the
same in a totally different implementation of an ATM
that interacts with the same bank.
122
123
Package diagrams show packages contained in
one view and how they relate to each other

124
Subsystem diagrams
 The UML provides a graphical representation for systems
and subsystems
 Subsystem diagrams helps to visualize the decomposition
of a system into smaller subsystems.
 Graphically, a system and a subsystem are rendered as a
stereotyped package icon.
 A system, possibly decomposed into a collection of
subsystems
 A system is the thing itself that you are developing

and for which you build models.

125
Diagram of Systems and
Subsystems

126
Course Registration Subsystem diagram

127
Component diagrams
 A component is a physical and replaceable part of a system
that conforms to and provides the realization of a set of
interfaces.
 “… a modular, deployable, and replaceable part of a
system that encapsulates implementation and exposes a set
of interfaces.”
 The component diagram's main purpose is to show the
structural relationships between the components of a system
 A component diagram provides a physical view of the
system.
 It focuses on a set of components and the structural
relationships among them.
 Its purpose is to show the dependencies that the software
has on the other software components (e.g., software
libraries) in the system.
128
 You use components to model the physical things that may
reside on a node, such as:
 executables
 libraries
 Tables
 Files and
 documents.
 In software, many operating systems and programming
languages directly support the concept of a component.

129
design of a Component diagram for Book Bank
Management System

130
Deployment diagrams
 A deployment diagrams
 shows how the finished system will be deployed on one or
more machines.
 are used to visualize the topology of the physical
components of a system where the software components are
deployed.
 are used for describing the hardware components where
software components are deployed.
 Component diagrams and deployment diagrams are
closely related.

131
Deployment diagram shows the configuration of
run time processing nodes and the components that
live on them.
 A deployment diagram can include all sorts of
features such as:
 Machines
 Processes
 Files and
 dependencies.
 Deployment diagrams are used:
1. To model embedded systems.
2. To model client/ server systems.
3. To model fully distributed systems.
132
Deployment diagram of an order management system

133
 Deployment diagram showing run-time nodes
and components for a browser-based three-tier
account management system

134
Component-Level Design
 Describes the internal detail of each software component
 Defines
 Data structures for all local data objects
 Algorithmic detail for all component processing functions
 Interface that allows access to all component operations
 Modeled using UML component diagrams, UML activity
diagrams, and pseudo code (PDL)

135
Deployment-Level Design
 Indicateshow software functionality and
subsystems will be allocated within the physical
computing environment
 Modeled using UML deployment diagrams

136
User Interface Design
 Specifying the interfaces between the parts of the system.
 Interface is a set of operations that describes the externally
observable behavior of a class and provides access to its operations
 Important elements
 User interface (UI)
 External interfaces to other systems
 Internal interfaces between various design components
 Modeled using UML collaboration diagrams
 User interface is the front-end application view to which user
interacts in order to use the software.

137
 User can manipulate and control the software as well as
hardware by means of user interface.
 Today, user interface is found at almost every place where
digital technology exists, right from computers, mobile phones,
cars, music players, airplanes, ships etc.
 User interfaces should be designed to match the skills,
experience and expectations of its anticipated users.
 System users often judge a system by its
interface rather than its functionality.
 A poorly designed interface can cause a user to make
catastrophic errors.
 Poor user interface design is the reason why so many software
systems are never used.
 UI provides fundamental platform for human computer
interaction
 UI can be graphical, text-based, audio-video based, depending
upon the underlying hardware and software combination.
138
 The software becomes more popular if its user interface is:
 Attractive

 Simple to use

 Responsive in short time

 Clear to understand

 Consistent on all interfacing screens

 UI is broadly divided into two categories:

 Command Line Interface

 Graphical User Interface

Command Line Interface(CLI)

 CLI provides a command prompt, the place where the user types

the command and feeds to the system.

 The user needs to remember the syntax of command and its use.

139
Graphical User Interface
 Graphical User Interface provides the user graphical

means to interact with the system.

 GUI can be combination of both hardware and software.

Using GUI, user interprets the software.

 Typically, GUI is more resource consuming than that of

CLI.
 With advancing technology, the programmers and

designers create complex GUI designs that work with

more efficiency, accuracy and speed.

140
Human factors in interface design
 Limited short-term memory
 People can instantaneously remember about 7 items of
information. If you present more than this, they are more
liable to make mistakes.
 People make mistakes
 When people make mistakes and systems go wrong,
inappropriate alarms and messages can increase stress and
hence the likelihood of more mistakes.
 People are different
 People have a wide range of physical capabilities.
Designers should not just design for their own capabilities.
 People have different interaction preferences
 Some like pictures, some like text.
141
UI design principles
 User familiarity
 The interface should be based on user-oriented terms
and concepts rather than computer concepts
 E.g., an office system should use concepts such as
letters, documents, folders etc. rather than directories,
file identifiers, etc. be similar, etc.
 Consistency
 The system should display an appropriate level of
consistency
 Commands and menus should have the same format,
command punctuation should be similar, etc.
142
 Minimal surprise
 If a command operates in a known way, the user should be

able to predict the operation of comparable commands

 Recoverability
 The system should provide some interface to user errors

and allow the user to recover from errors

 User guidance
 Some user guidance such as help systems, on-line manuals,

etc. should be supplied

 User diversity
 Interaction facilities for different types of user should be

supported
 E.g., some users have seeing difficulties and so larger text

should be available 143

Summary
 The software architecture is the fundamental
framework for structuring the system.
 The user interface design process involves user

analysis, system prototyping and prototype

evaluation.

144
A general model of the design process

145
Analysis Model to Design Model
Component-level Design

(Class-based model, Flow-oriented model

Behavioral model)
Interface Design

(Scenario-based model, Flow-oriented model

Behavioral model)

Architectural Design

(Class-based model, Flow-oriented model)

Data/Class Design

(Class-based model, Behavioral model)

146
Con’t

147
Thank you
Any ?

148