Scribd
Upload
12 views20 pages

Session 2 - Good Design Concepts - Complete

The document outlines key software design principles and concepts, emphasizing the importance of modularity, information hiding, cohesion, and coupling in creating effective software architecture. It distinguishes between prescriptive and descriptive architecture, highlighting the differences between intended and realized designs. Additionally, it discusses various software design methods and typical design trade-offs that developers face.

Uploaded by

shanireal420
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
12 views20 pages

Session 2 - Good Design Concepts - Complete

The document outlines key software design principles and concepts, emphasizing the importance of modularity, information hiding, cohesion, and coupling in creating effective software architecture. It distinguishes between prescriptive and descriptive architecture, highlighting the differences between intended and realized designs. Additionally, it discusses various software design methods and typical design trade-offs that developers face.

Uploaded by

shanireal420
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

SOFTWARE DESIGN

AND ARCHITECTURE
Good Design Concepts 1
OUTLINE
▪ Software Design Principles
▪ Design Process Concepts
▪ Modularity
▪ Information Hiding
▪ Cohesion
▪ Coupling
▪ Functional Independence

▪ Prescriptive Vs. Descriptive Architecture

2
SOFTWARE DESIGN PRINCIPLES
▪ Design is not coding, coding is not design

▪ The design should be structured to


accommodate change (the more modular the
better)
▪ The design should be assessed for quality as it is
being created

3
4
CONCEPTS IN DESIGN
MODULAR DESIGN
▪ Easier to manage
▪ Easier to understand
▪ Reduces complexity
▪ Delegation / division of work
▪ Fault isolation
▪ Independent development
▪ Separation of concerns
▪ Reuse

5
EFFECTIVE MODULAR DESIGN
▪ How to decompose a software system into
best set of modules?
▪ Information hiding
▪ Cohesion
▪ Coupling
▪ Functional independence

6
INFORMATION HIDING
▪ Design the modules in such a way that
information (data & procedures) contained in
one module is inaccessible to other modules
that have no need for such information.

▪ Independent modules.
▪ Benefits:
▪ when modifications are required, it reduces the
chances of propagating to other modules.

7
COHESION
▪ “A module should ideally do one thing.”
▪ Each module performs a single task requiring
little interaction with other modules.
▪ A cohesive module since accomplished neatly
defined single task so it can be re-used in
other projects
▪ High cohesion is good
▪ Changes are likely to be local to a module
▪ Easier to understand a module in isolation

8
COUPLING
▪ A measure of interconnection among modules in
a software structure
▪ Depends on the interface complexity between
the modules
▪ High coupling causes problems
▪ Change propagation- ripple effect
▪ Difficulty in understanding
▪ Difficult reuse

9
Cohesion Coupling
Cohesion is the concept of intra- Coupling is the concept of inter-
module. module.
Cohesion represents the Coupling represents the
relationship within a module. relationships between modules.
Increasing cohesion is good for Increasing coupling is avoided for
software. software.
Cohesion represents the functional Coupling represents the
strength of modules. independence among modules.
Highly cohesive gives the best Whereas loosely coupling gives
software. the best software.
In cohesion, the module focuses on In coupling, modules are
a single thing. connected to the other modules.

10
FUNCTIONAL INDEPENDENCE
▪ A module having high cohesion and low coupling
is said to be functionally independent of other
modules.

▪ Each module addresses a specific sub function of


requirements and is easier to maintain or modify
▪ Benefits:
▪ Error isolation
▪ Scope of Re-use
▪ Understandability

11
TEMPORAL ASPECT
▪ Design decisions are and unmade over a
system’s lifetime
→ Architecture has a temporal aspect
▪ At any given point in time the system has
only one architecture
▪ A system’s architecture will change over time

12
PRESCRIPTIVE VS. DESCRIPTIVE
ARCHITECTURE
▪ A system’s prescriptive architecture captures the
design decisions made prior to the system’s
construction
▪ It is the as-conceived or as-intended architecture

▪ A system’s descriptive architecture describes


how the system has been built
▪ It is the as-implemented or as-realized architecture

13
AS-DESIGNED VS. AS-IMPLEMENTED ARCHITECTURE

14
AS-DESIGNED VS. AS-IMPLEMENTED ARCHITECTURE

▪ Which architecture is “correct”?


▪ Are the two architectures consistent with
one another?
▪ What criteria are used to establish the
consistency between the two architectures?
▪ On what information is the answer to the
preceding questions based?

15 15
16
SOFTWARE DESIGN
METHODS
SOFTWARE DESIGN METHODS
▪ Systematic approaches to developing a
software design.
▪ Structured (Function-Oriented)
▪ Object-Oriented
▪ Data-Oriented (Data-structure-centered)
▪ Component-based
▪ Formal Methods

17
WHICH METHOD TO CHOOSE?
▪ Data oriented design is useful for systems
that process lots of data, e.g. database and
banking applications

▪ Structured design is useful for process


intensive systems that will be programmed
using a procedural language such as C.

▪ OO methods are useful for any system that


will be programmed using an object
oriented language such as C++.
18
▪ Component-based Methods are used for
the large systems that can be modularized.

▪ Formal methods are considered to be an


alternative to OO and classical design
methods,
▪ However, the ability to formally validate the
correctness of a software artifact is appealing and
research on formal methods is ongoing.

19
TYPICAL DESIGN TRADE-OFFS

▪ Security vs. Efficiency


▪ Efficiency vs. Portability
▪ Correctness vs. Reliability
▪ Backward Compatibility vs. Cost
▪ Integrity vs. Efficiency
▪ Usability vs. Efficiency

20

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy