CHAPTER 5: SYSTEM

DESIGN
Software Design
obtain a solution which satisfies software
requirements
Software Design
Design activity begins with a set of
requirements, and analysis of them.
Design is done before the system
implemented
Design focuses on module view – i.e.
what modules should be in the system
Design of a system is a blueprint/plan
for implementation
SW architecture definition constitutes a
High level design (modules are defined),
this includes (logic and physical design.

Design is a creative activity

Goal: to create a plan to satisfy
requirements
Perhaps the most critical activity during
system development.
Design…
Has great impact on testing and
maintenance
Design document forms reference for
later phases
Design is correct, if it will satisfy all the
requirements .

Of the correct designs, we want best

design

We focus on modularity as the main

criteria (besides correctness)
Modularity
Modular system – in which modules can
be built separately and changes in one
have minimum impact on others

Modularity enhances design clarity, eases

implementation

Reduces cost of testing, debugging and

maintenance
Cannot simply split a program into
modules to get modularly.

Need some criteria for decomposition –

coupling and cohesion, and Open-
Closed principles are such criteria
Modules can be treated “independently”:
can understand and use each module in
isolation
failure in one module doesn’t affect other
modules, so easier to isolate failures
change in one module doesn’t affect other
modules.
1. Coupling
Two modules are independent only if it can
function completely without presence of the
other.
Coupling is a measure of the dependencies
between two part of a system. If two classes
are strongly coupled, it is hard to modify one
without modifying the other.
Strength of interaction between objects in
system.
 Coupling
Independence between modules is desirable
Modules can be modified separately
Can be implemented and tested
separately
In a system all modules cannot be
independent
 Modules must cooperate with each other
Coupling…
In general, the more we must know about
module A in order to understand module B
the more closely connected is A to B
"Highly coupled" modules are joined by
strong interconnection.
"Loosely coupled" modules have weak
interconnections; means component
changes are unlikely to affect other
components.
 Loose Coupling
Module A

A’s data

Module B Module C
B’s data C’s data

Module D

D’s data
High coupling makes modifying parts of
the system difficult, e.g., modifying a
component affects all the components to
which the component is connected.

Goal: modules as loosely coupled as

possible
2. Cohesion
A measure of how well components “fit
together”.
Cohesion is a measure of dependencies
within part of a system. If a class contains
many closely related functions its cohesion
is high.
Degree to which the tasks performed by a
single module are functionally related
Aim for high cohesion within entities
and weak coupling between them;
Cohesion and coupling are interrelated;
3. Open-closed Principle
Besides cohesion and coupling, open
closed principle also helps in achieving
modularity

Principle: A module should be open for

extension but closed for modification

Behavior can be extended to

accommodate new requirements, but
existing code is not modified
I.e. allows addition of code, but not
modification of existing code
Minimizes risk of having existing
functionality stop working due to
changes – a very important
consideration while changing code
Good for programmers as they like
writing new code
Data Modeling
Data modeling is an important part of
database design. The data model focuses
on what data should be stored in the
database, exploring the relation between
data entities.
The goal of the data model is to ensure
that all data object required by the
database is accurately represented.
It provides the overall logical structure
(the blueprint) of the database.
Logical Model
The Entity Relationship model views the
real world as the set of entities and
relationships between them.
Logical design involves defining business
entities, attributes for each entity, and
relationships among entities.
The latter are sometimes referred to as
cardinality.
Basic elements in an ER Diagram
ERD symbols
1. Entity
Entity may be a person, place, event, concept,
or object that is relevant to a given system.
 Person: EMPLOYEE, STUDENT, PATIENT,
TEACHER
 Place: STORE, WAREHOUSE
 Object: MACHINE, PRODUCT, CAR
 Event: SALE,REGISTRATION, RENEWAL
 Concept: ACCOUNT, COURSE
Entities are represented in ER diagrams by
a rectangle and named using singular
nouns.
2. Attribute

An attribute is a property, trait, or

characteristic of an entity, relationship,
or another attribute.
Meanwhile, attributes can also have their
own specific attributes.
 For example, the attribute “customer
address” can have the attributes number,
street, city, and state. These are called
composite attributes.
Attributes are represented by oval
shapes.
Composite attributes
3. Relationship
A relationship describes how entities
interact.
For example, the entity “Student” may be
related to the entity “Course” by the
relationship “takes”

Relationships are represented by

diamond shapes and are labeled using
verbs.
A relationship describes how entities
interact.
For example, the entity “carpenter” may
be related to the entity “table” by the
relationship “builds” or “makes”.
Descriptive attributes
A relationship may also have attributes
like an entity.
These attributes are called descriptive
attributes.
E.g. Student gets degree certificate on 14th
March 2011. Student and Degree are
entities, gets certificate is relation and
certificate date is an attribute of relation.
4. Cardinality
Cardinality of a relationship expresses the
number of entities that can be associated.
This further defines relationships between
entities by placing the relationship in the
context of numbers.
Cardinality exists in four types:
one-to-one, 1:1
one-to-many, 1:N
many-to-one, M:1 and
many-to-many, M:N.
• How two or more entities are related (if at
all…)
• Cardinality
– 1:1 (wife-husband)
– 1:N (mother-children)
– N:M (grandparents-grandchildren)

– In an email system, for example, one

account can have multiple contacts.
The relationship in this case follows a
“one to many” model.
One-to-One relationship
One-to-One relationship (1:1)
The students and the Student card: Every
student can have at most one Student card
and every Student card can belong to at
most one student.
One-To-Many Relationship
One-To-Many Relationship
One-to-Many relationship
Members and books of a library: A
member can borrow many books but a
book can be borrowed by only one person
at a time.
Many-to-many relationship
Student can take many courses and a course can be attended by many student
Recursive Relationships (Unary Relationships)
Sometimes an entity refers back to itself.
An employee has a boss; and the
boss/chef is an employee too.
The attribute 'boss' of the entity
'employees' refers back to the entity
'employees'.
Key concepts
A superkey is a nonempty set of
attributes which allows us to uniquely
identify an entity of the entity set.
A superkey which does not have a proper
subset is called a candidate key.
A primary key (PK) is a candidate key
which is chosen by the database
administrator to identify entities in an
entity set. And is a column with a unique
value for each row. No table should be
without one.
Foreign Key (FK) These define
relationships between tables. When you
want a row in one table to be linked to a
row in another table, you place a FK
column in the child table and use the value
of the parent row's PK as the value of the
FK field.
Composite Key This is a key that is made up
of more than one column. This is typically
used when you want to prevent a table from
using the same combination of values twice.
STEPS TO CONSTRUCT ENTITY RELATIONSHIP DIAGRAMS

1. Identify entities – use DFDs to identify

entities (Data stores).
2. Add attributes – requires detailed
analysis and perhaps use of requirements
gathering techniques.
3. Assign identifiers or Primary keys –
Each entity type must have an attribute or
set of attributes that distinguishes one
instance from other instances of the same
type.
Steps…
4. Identify Relationships – involves
establishing the cardinality and the
modularity of each relationship
An entity should appear only once in a
particular diagram.
Provide a precise and appropriate name for
each entity, attribute, and relationship in
the diagram.
In naming entities, remember to use
singular nouns. However, adjectives may
be used to distinguish entities belonging
to the same class (part-time employee and
full time employee, for example).

Meanwhile attribute names must be

meaningful, unique, system-independent,
and easily understandable.
Remove vague, redundant or
unnecessary relationships between
entities.
Never connect a relationship to another
relationship.
Make effective use of colors. You can use
colors to classify similar entities or to
highlight key areas in your diagrams.
Data dictionary
 The data dictionary is a reference work of
data about data (metadata).
 It collects, coordinates, and confirms what

a specific data term means to different

people in the organization.
 Data dictionaries are created by making a

detailed analysis of the data flows, data

stores, and processes in data flow
diagrams.
 The data dictionary may be used for the
following reasons:
Provide documentation
Eliminate redundancy
Validate the data flow diagram for
completeness and accuracy
Provide a starting point for developing
screens and reports
Determine the contents of data that is
stored
Creating a data dictionary is an iterative
and evolutionary process that should be
carried out in parallel to the systems
analysis and design.
Exercises 1
Book -the set all the books in the library. Each
book has a Book_id, Title, Author, Price, and
Available (y or n) as its attributes.
Member-the set all the library members. The
member has Member_id, Name, Street, City,
Mem_type, Mem_date (date of membership),
Expiry_date. Member borrows books.
Publisher-the set of all the publishers of the
books. Attributes of this entity are Pub_id,
Name, Street, City.
Supplier-the set of all the Suppliers of the
books. Attributes of this entity are Sup_id,
Name, Street, City.
Exercise 2
A university consists of several faculties.
Within each faculty there are several
departments. Each department may run a
number of courses. All teaching staff are
attached to departments, each staff member
belonging to a unique department.
Every course is composed of subcourses.
Some subcourses are part of more than one
course. Staff may teach on many subcourses
and each sub course may be taught by a
number of staff.
Draw an entity-relationship model for this
example. Show also cardinalities.
Exercise 3
Draw a ERD representing a book defined
by the following statement:
“A book is composed of a number of parts,
which in
turn are composed of a number of chapters.
Chapters are composed of sections.”
Focus on ENTITIES, relationships and add
multiplicity.
ERD STELLA
Diagrams overloaded with details are
difficult to read and understand
EDRAW UML DIAGRAM 7
Entity Relationship Diagram

FILE --- NEW --- DATABASE --- CHEN

ERD