260CT Software Engineering

Short Notes
By: Salman Fazal

Contents
SE Overview .. 1
(Objectives, Principles, Methodologies)

Architectural Design patterns 8

GRASP 12
OO Design Principles . 17
GoF Design Patterns . 21
Data Mapping Patterns 25
Anti-design Patterns & Exam Topics .. 30
 260CT Notes
Salman Fazal

Software Engineering Overview

1
The process of solving customers problems by the systematic and organised development of high-
quality software systems within cost, time and other constraints.
2
Its a discipline that is concerned with all aspects of software production, including;

o Software development process

o Project Management
o Tools, methods and theories adopted

Validation Test if the product is specified to the users actual needs.

Verification Test if the product follows the specification (i.e. do the product meet all use cases?).

OBJECTIVES:
To produce software:
1. On time
2. To budget
3. With required quality. Eg:
- Maintainability: Software should be able to meet needed changes.
- Reliability: Software must be trustworthy, dependable.
- Efficiency: Software should not make waste of system resources
- Usability: Software must be usable by the users (specifically designed for).

PRINCIPLES:

Principles form the basis of methods, techniques, methodologies and tools

Definitions:

- Methods & Techniques: A (systematic)

way of doing things; general guidelines.

- Methodologies: A certain approach to

solving a problem by selecting the
methods & techniques to be used.

- Tools: Developed to support the

application of methods, techniques and
methodologies.

Seven important principles of software engineering for the success of a software project.

Principle 1. Separation of Concerns

Principle 2. Modularity
Principle 3. Incrementality
Principle 4. Abstraction
Principle 5. Generality
Principle 6. Anticipation of Change
Principle 7. Rigor and Formality

2
 260CT Notes
Salman Fazal

Principle 1: Separation of Concerns

Divide and Conquer

Tackles with the complexity of large systems, by separating different issues to concentrate on one at
a time. This minimizes interdependence (connection) and increases reusability.

Issues/Concerns can be
i. Functional (views) Describes what the system will
do. (Layer separation (MVC), data, network, etc)
ii. Non-functional (qualities) Concerns how well the
system provides functional requirements (efficiency,
reliability, usability, etc).
More in the extras.

Example:

Web 1.0: HTML, CSS and Javascript all in the same

HTML code.
Web 2.0: All three separated into different segments.

Principle 3: Incrementality

Grow, dont build

Process proceeds in separate stages (increments)

- delivers subsets of a system at early stages or a prototype for feedback from the clients or
expected users, from which new features are added incrementally

- Deals with functionality first, then comes performance.

Prototyping model: quick design focusing on aspects of software, organised and evaluated and
refined through iteration

3
 260CT Notes
Salman Fazal

Principle 5: Generality

If you think you have already discovered a solution, think againbut with a more open mind!

While solving a problem, try to discover if it is an occurrence of a more general problem whose
solution can be reused in other cases (ie. similar patterns). Sometimes, a general problem is easier
to solve than a special case.

Component-based Development Model

This approach is based on systematic reuse where systems are integrated from existing components
or COTS (Commercial-off-the-shelf) systems. Process stages include:

Component analysis;
Requirements modification;
System design with reuse;
Development and integration.

Reuse is now the standard approach for building many types of business system.

Principle 6: Anticipation of Change

Software changes all the time!

Anticipates potential future changes with ability to support software evolution.

CAREFUL! That is not about try to implement what users will MAYBE need in the future. That is
about to be prepared to change!

Principle 7: Rigor and Formality

Software engineering is a creative design activity, BUT It must be practiced systematically

Rigor: the quality or state of being very exact, careful, or strict.

Enables repeatability and allows teams to avoid problems experienced in past projects.

Formality: the highest degree of rigor

Software process driven and evaluated by mathematical laws;
E.g. mathematical analysis of program correctness for a software product.

4
 260CT Notes
Salman Fazal

METHODOLOGIES

A methodology defines an approach to be used in software development to produce high-quality

and cost-effective software in a systematic manner.

- Structured (function-oriented)
- Object-oriented
- Agile

Structured

Processes manipulate data and show how they transform data objects that flow through the
system.

The program is represented as a logical structure, the flow of execution of the program is
dependent on the structure of the program.

Example of a modelling technique is Flowcharts.

Object-oriented

Based on the concept of objects in which data is encapsulated with the functions that act on the
data

The program is written as a collection of objects which communicate with each other. The basic
entity is object, each computation is performed using objects only.

Example of a modelling technique is UML (Class diagrams, use cases, sequence diagrams).

UML (Unified Modelling Language): a standard language for visualising, specifying, constructing and
documenting software artefacts.

5
 260CT Notes
Salman Fazal

AGILE

Agile processes use feedback, driven by regular tests and releases of evolving software.

Agile: SCRUM

Scrum is an iterative and incremental agile framework for managing software projects that helps
team deliver projects very early and often in a highly predictable manner.

Applies to techniques, such as:

- Sprints: A fixed time frame for each of the iterations
- Product Backlog: A prioritized list of functionalities to develop
- Daily Scrum: A daily meeting headed by the scrum master

- Iterative: through sprints in which

software process and activities are
repeated in iterations (image 1)

- Incremental: a working
functionality is delivered at the end
of each sprint (image 2)

6
 260CT Notes
Salman Fazal

Agile: Extreme Programming (XP)

Improve software quality and responsiveness to changing customer requirements.

- Frequent releases in short development cycles. Development delivery of small

increments of functionality.
- Improve productivity and regular checkpoints with the customer
- Paired programming demands that every bit of the code is developed by a pair of
programmers, one is involved in the actual building of the code, and the other
supports and reviews.

Extras

Functional Requirements something the system must do

Non-functional Requirements a property or quality the system must have:

Performance speed or response time of the system.

Security e.g. resistance to attacks.
Availability minimal downtime.
Usability system meets user needs and tasks to undertake. Usability should achieve the
effectiveness, efficiency and user satisfaction of the tasks undertaken.

Reverse Engineering: the process of analysing an existing system to identify its components and
create representations of the system in another form.

- Decompilation, a type of reverse engineering, to convert executable program code

into a form of higher-level programming language readable by human.

Forward Engineering: traditional software engineering approach starting with requirements analysis
and progressing to implementation of a system.

- If existing source code, you reconstruct the existing system to improve its overall
quality or performance.

Round-trip Engineering: Combination of reverse and forward engineering. It synchronises two or

more related software artefacts, such as source code, models or other documents. It performs a
continuous alignment between source code and the models/diagrams.

Re-engineering: process of reorganising and modifying the existing system to make them more
maintainable. This is modified by first reverse engineering, then code reconstructing the finally
forward engineering.

7
 260CT Notes
Salman Fazal

Software Application Architecture

- The process of defining a structured solution that meets all of the technical and operational
requirements.
- Involves optimizing common quality attributes such as performance, security, and manageability.
- Focuses on how components within an application interact with each other within the application.

Application Architectural Designs

2-TIER ARCHITECTURE

Separates the system into two applications, client and server. Client computers directly connect to
and request results from database server, and server sends response directly to client.

Tiers: Presentation Tier and Database Tier

Advantages:

- Easy to maintain and modification is bit easy

- Communication is faster

Disadvantages:

- In two tier architecture application performance will

be degrade upon increasing the users.
- Cost-ineffective

2-Tier Peer-To-Peer (P2P)

Every peer (node) are interconnected with each

other and share resources with each other without a
central controlling server.

3-TIER ARCHITECTURE

An application tier exists between the client and the database server. Clients make requests to the
application server, which then sends the request to the database server. The database sends the
response back to the middle tier which sends the results to the client.

Tiers: Presentation (Client) Tier, Business (Application) Tier and Database Tier

8
 260CT Notes
Salman Fazal

This architectural design evolved from 2-Tier to address issues with better:

- Maintainability: Tiers are independent to each other; updates or changes can be carried out
without affecting the application as a whole.

- Scalability: Application servers can be distributed on many machines and database no longer
requires a connection from every client. Thus easy to scale out.

- Flexibility: Each tier is managed independently therefore its more flexible.

N-TIER ARCHITECTURE

A client-server architecture in which, the presentation, the application processing and the data
management are logically separate processes. N is a number, can be 1 or above.

COMPONENT-BASED ARCHITECTURE

Decomposes application into

reusable functional or logical
components. This would require
well-defined communication
interfaces

9
 260CT Notes
Salman Fazal

LAYERED ARCHITECTURE

Partitions the concerns of the application into stacked groups (layers).

Layered vs. Tiered architecture: the layers of an application may be present in on the same physical
computer (the same tier) or may be distributed over separate computers (n-tier).

Client presenter layer: contains the presentation logic, i.e. how business objects are displayed to
users, e.g. the pop-up screens or drop-down menus
Business layer (also domain layer): handles and encapsulates all of business domains and rules.
Persistence layer: handles the read/write of the business data to the data access layer (DAL).
Data access layer: an external data source, e.g. a database.

The Static Model of a software design includes three stereotypes that differentiate the roles objects
can play:
Boundary classes: to handle communication with actors. Basically, the user interface and windows
classes.
Entity/data classes: to represent something (from the application domain) about which the system
must store information.
Control classes: mediates (controls & coordinates) between boundary and entity classes.
Deal with business/application logic, such as register new patients.

4 Layered Architecture
User Interface Layer contains boundary classes (e.g. GUI objects) to handle input and output with
the external actors.
Application Logic Layer control classes are added to coordinate the application logic for each use
case.
Domain/data Layer data objects contained in data classes.
Data Access/Persistence Layer handles reading/writing to an underlying database or files.

10
 260CT Notes
Salman Fazal

MVC ARCHITECTURE

Modelviewcontroller (MVC) is a software design pattern for implementing user interfaces on

computers. It divides a given software application into three interconnected parts, The Model, View
and Controller.

Model: represents an object or data (the database)

View: represents the visualization of the data that model contains (what end user sees).
Controller: controls the data flow into model object and updates the view whenever data changes
(Receives requests from the view and sends back data from the model).

Benefits:
Support multiple views:
user interface can display
multiple views of the same
data at the same time
Accommodate changes:
Changes to the user
interface (theme, layouts)
does not affect the model.

11
 260CT Notes
Salman Fazal

GRASP (Design Pattern)

Pattern A principle used that provide guidance in the creation of software. Have a name, problem
description and problem solution.
Design Pattern a general repeatable solution to a commonly occurring problem in software
design. A design pattern isn't a finished design that can be transformed directly into code. It is a
description or template for how to solve a problem that can be used in many different situations.

o Architectural Patterns Presenting an essential structural schema for a software system.

E.g. MVC
o Design Patterns Providing a scheme for refining the components of a software system.
- General patterns (guidelines) for assigning responsibility to classes and objects.
E.g. the GRASP set of patterns.

The GRASP Patterns

GRASP (General Responsibility Assignment Software Patterns) encompass nine objectoriented

design principles related to creating responsibilities for classes and defining objects.

Grasp Patters:

Controller, creator, indirection, information expert, high cohesion, low coupling, polymorphism,
dont talk to strangers, and pure fabrication. All these patterns answer some software problem.

GRASP Pattern: Cohesion & Coupling

Cohesion refers to what the class will do. Low cohesion means the class does a great variety of
actions and is not focused on what is should do. High cohesion means that the class is focused on
what it should be doing

Low Cohesion High Cohesion

------------------- ----------------------------
| Staff | | Staff |
------------------- ----------------------------
| checkEmail() | | -salary |
| sendEmail() | | -emailAddr |
| emailValidate() | ----------------------------
| PrintLetter() | | setSalary(newSalary) |
------------------- | getSalary() |
| setEmailAddr(newEmail) |
| getEmailAddr() |
----------------------------

Coupling refers to how two classes are related to each other. Low coupling means changing
something major in one class should not affect the other. High coupling would make it difficult to
make the changes.

A good software design will go for high cohesion and low coupling.

12
 260CT Notes
Salman Fazal

GRASP Pattern: Controller

This is an object just below the UI layer that controls the systems operations.

Problem: Who should be responsible for handling UI events? (Ie. End Sale, Make Payment, Enter
Item in a POS system)

Solution: Assign responsibility to receive or handling a system events in one of these ways:

- Faade controller: One class that represents and control the entire system

- Role Controller: One class that represents a role (an actor) and controls all functionality by
that actor.

- Use Case Controller: One class represents a use case (within which a system event occurs)
and controls its functionality.

*Faade is suitable when there are no too many events, however its a less desirable solution as it
leads to low cohesion and high coupling.

GRASP Pattern: Information Expert

This is a class that has information necessary to fulfil some responsibility.

Problem: How to assign responsibilities to objects?

13
 260CT Notes
Salman Fazal

Solution: Assign responsibility to the class that has the information necessary to fulfil it (the
information expert).

Example: Consider,

Which class should be responsible for calculating the grand total of the sale?

While the Product class can determine the value of an individual items, they cannot determine the
final mark. The Sale class should be assigned this responsibility since it knows about all of the Sale
Detail class. The Sale class will rely on the Product class to determine the individual prices.

The Expert pattern has a real-world analogy, who do you ask about X, you ask the expert who knows
about X.

GRASP Pattern: Creator

Who creates a particular object?

Problem: Whos responsible to create an instance of class A?

Solution: Assign B to create an instance of A if one the following is true:

- B contains/aggregates A
- B records A
- B closely uses A
- B has data needed to create an A object.

In the above diagram, which class should be responsible for creating the Sale Detail object?
Since the Sale aggregates Sales Detail, Sale should be the creator.

GRASP Pattern: Polymorphism

Usually means the use of a super (parent) class.

Problem: How to handle related but varying elements based on element type? How to create
pluggable software components? (Replace one component without affecting the main component).

Solution: Use polymorphism to assign responsibilities on classes when the behaviour changes.

14
 260CT Notes
Salman Fazal

GRASP Pattern: Pure fabrication

Problem: How to assign responsibilities when you do not want to violate High Cohesion and Low
Coupling (solutions offered by Information Expert are not appropriate)?

Solution: Assign the responsibility to an artificial class that doesnt belong to the domain model
something made up in order to support high cohesion, low coupling and reuse.

Example;

- Suppose we need to save instances of SaleClass in a database, which class do we assign this
responsibility to?
- To manage data going to and from a database will require numerous operations, insert,
delete, update, select, commit
- The information expert suggests that SaleClass is the expert so the functions should be in
that class. However, we would end up adding a lot to SaleClass which is not really related.
- Pure Fabrication suggests to create a new class for these responsibilities.

<- Class is fabricated (made up), and is not found in the domain
model.

SaleClass remains well-designed (high cohesion, low coupling).

GRASP Pattern: Indirection

Problem: Where to assign a responsibility, to avoid direct coupling between two (or more) things?
How to decouple objects so that low coupling is supported and reuse potential remains higher?

Solution: Assign the responsibility to an intermediate object to mediate between other components
or services so that they are not directly coupled.

15
 260CT Notes
Salman Fazal

GRASP Pattern: Law Of Demeter

Dont talk to strangers. Each class should only talk to its friends (close ones)

The Law of Demeter places constraints on what objects you should send messages to within a
method. It states that within a method, messages should only be sent to the following objects:

1. The this object (or self).

2. A parameter of the method.
3. An attribute of this.
4. An element of a collection which is an attribute of this.
5. An object created within the method.

Notes

__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________
__________________________________________________________________________________

16
 260CT Notes
Salman Fazal

OO Design and Principles

ABSTRACTION

The developer and other objects in the system have a high-level summary view (an abstract view) of
what data items are and operations provided. The details of how the data and methods (procedure)
are stored and coded are ignored.

Types of abstraction:
1. Data (Summary of data items). Contains only the required information about the object.
2. Procedural (Summary of operations). Sequence of instructions that have a specific and
limited function. The details and how the methods are coded are ignored.

ENCAPSULATION

The attributes (data) relating to an object and the methods that manipulate them are encapsulated
inside a single software capsule (unit). This keeps both (public variables and methods) safe from
outside interference and misuse.

Encapsulate components via aggregation and composition.

Aggregation child can exist independently without parent. Eg. Library and students
Composition child cannot exist independently without parent. Eg. Library and books.

17
 260CT Notes
Salman Fazal

INFORMATION HIDING

Data Hiding the developer and other objects in the system have no direct access to the attributes
(which are private) or the detail of how the attributes are stored.

Procedural Hiding The developer or other objects in the system do not know the detail of how the
methods work. The name of a method is public but the code body of the method is private.

They access the data via accessor methods (get methods) and modify the data via mutator
methods (set methods)

SEPERATION OF CONCERNS

Any complex problem can be more easily handled if it is subdivided into pieces. Separation of
Concerns is the idea of dividing an application into distinct components that overlap in functionality
as little as possible. Eg. Layered architecture or MVC

18
 260CT Notes
Salman Fazal

MODULARITY

(Relating to separation of concerns). A complex software may be divided into smaller

components/modules according to functionality and responsibility.

Supports application of separation of concerns. When dealing with a module we can ignore details of
other modules. Modules should be highly cohesive and closely related.

Example:
In a student registration system, the system is separated into classes (i.e. modules), Student and
Courses according to their functionality and responsibilities. When dealing with the Student class,
the details of other classes are ignored.

HIGH COHESION

Cohesion refers to what the class will do. Low cohesion means the class does a great variety of
actions and is not focused on what is should do. High cohesion means that the class is focused on
what it should be doing.

A class should only have attributes and operations closely related to its objects or a group of clearly
defined processes that are related in terms of functionality.

LOW COUPLING

Coupling refers to how two classes are related to each other. Low coupling means changing
something major in one class should not affect the other. High coupling would make it difficult to
make the changes.

Classes should exhibit low coupling. Classes should have low interactions with others, in terms of
messages an object send to another object and the number of parameter passed with the object.

19
 260CT Notes
Salman Fazal

REUSABILITY

Reusability is a principle whose importance derives from the desire to avoid duplication in
undertaking classes of inherently similar tasks.

A group of classes is encapsulated collectively for a reuse subassembly, as a complex whole is made
of similar components (parts); more parts can be added to the whole component.

It also allows the creation of new specialised classes when needed, as new specialised subclasses will
inherit the characteristics of existing generalised super-classes.

Inheritance with reusability

<= Aggregation with reusability:

Initially the system is designed with University,

Department and Professor which forms an aggregation
association. Later when a Lecturer needs to be added to
the system, it can be added via aggregation, enhancing
reusability.

NOTES

Overload method name having several alternative implementations (compile time)_____________

Override child class provides alternate implementation for the parent class method (runtime)____

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

20
 260CT Notes
Salman Fazal

Gang of Four Design Patterns

Recap

Design patterns represent the best practices used by experienced OO software developers. Design
patterns are solutions to general problems during OO software development.
Design patterns provide a description of the interactions between objects and classes that are
adapted to solve general problems within a given context of software design.

There are 23 Design patterns which are categorised into three groups;

Creational patterns manages creation of classes and objects.

Structural patterns describes how classes and objects are connected together to build
structured (complex) objects.
Behavioural patterns specifies the way objects communicate with each other. Describes
how code is organized, to assign responsibility or roles to certain classes.

CREATIONAL PATTERNS
Deals with initializing and configuring classes and objects. They help in isolating how objects are
created, composed and represented from the rest of the system.

Creational Factory Method

Defines an interface for creating objects but lets the sub-classes decide which of those to instantiate.
- One or more methods are declared within the Factory class which create the object.
- Methods are then instantiated within the subclass based on clients information.

Useful when requiring the creation of many different types of objects, all derived from a common
base type.

21
 260CT Notes
Salman Fazal

Creational Abstract Factory Method

The abstract factory method provides one layer of abstraction above factory method, they work
around a super-factory which creates other factories.

In abstract factory pattern, an interface is responsible for creating a factory or related objects
without explicitly specifying their classes.

Abstract Class cannot be instantiated, but other classes can inherit from them
Interface Method with no implementation. Method must be overridden by the implemented
classes.

Creational Singleton

The singleton ensures that a class has only one possible instance.
- Private static attribute and constructor to ensure the class cannot be instantiated or
manipulated elsewhere outside of the class definition.
- Public static accessor method (getter).

Singleton Implementation:
- Lazy initialization delaying the creation of a field until its value it needed the first time.
- Lazy class loading class loaded into memory only where theyre first referenced.
- Lazy object initialization create an object until the first time it is needed.

22
 260CT Notes
Salman Fazal

Creational prototype

This design pattern is used for creating new objects (instances) by cloning (copying) other objects
and this way we can improve the performance. The pattern uses Java cloning to copy the object.

E.g. we need to load an object from a DB then modify its data in our program multiple times, its not
a good idea of creating objects (using new keyword) by loading all the data from the DB. A better
approach is to clone the existing object to a new one and then manipulate its data.

IcecreamCache

STRUCTURAL PATTERNS

Concerned with how classes and objects are composed to form larger structures.

Structural proxy

Proxy provides a placeholder for another object to control access to it. Proxy means represent or
on behalf or.

Provide a class which limits/controls access to the original class.

E.g. an ATM class has several methods, one being setting the cash. The proxy class will represent the
ATM class and will not have the setCash method. The client accesses the proxy instead of ATM class.

- Remote proxy provides a local representation of the object which is present in the
different address location.
- Smart proxy provides additional layer of security by interposing some actions when the
object is accessed.
- Protective proxy acts as an authorisation layer to verify if the actual user has access to
appropriate content.
- Virtual proxy useful to save expensive memory resources when there is an expensive
operation, multiple proxies can be created and pointed to the huge size memory consuming
object for further processing.
o Example a real image contains a huge size data which clients needs to access.
o Solution:
Image interface which has operation display().
RealImage runs on the different system and contains the image information
is accessed and loaded from the database.
ProxyImage which is running on a different system can represent the
RealImage in the new system.

23
 260CT Notes
Salman Fazal

BEHAVIOURAL PATTERNS

Behavioural observer

A design pattern in which an object, called the subject, maintains a lost of its dependants, called
observers, and notifies them automatically of any state changes, usually called by one of their
methods.

This defines a one-to-many dependancy between objects so that when one object changes state, all
of its dependants are notified and updated automatically.

Real world example: (online shopping)

- 3 people (observers) want to buy a certain item but its out of stock, they click on the notify
when in stock option; meaning they are registering themselves to that option (the subject).
- Once item is in stock, the status changes to available & the subject notifies the 3 observers.

24
 260CT Notes
Salman Fazal

Data Mapping & Patterns

Layered architecture review:

Data Persistence in OO:

1. Transient Data/Object (temporary data):

- Stored in the computers RAM. When a
program completes, the data is de-allocated.

2. Persistent Data/Object (permanent data):

- Permanent data stored in a file or database,
data still available when program completes.
- Must exist between executions of different
applications or be shared among different
instances of applications.

Persistence Mechanisms

Data hold in files of databases.

DBMS
- Relational DBMS: holds tables of data
- Object DBMS: holds objects (with attributes)
- Object-Relational DBMS: combines relational (simplicity) and object databases
(complexity)
- NoSQL: non-relational data - (open source, schema-less, distributed ).

Mapping Objects

The data access layer connects to an external data source (e.g. Database), there is a need to map the
objects in the application to tables in the database.

Sometimes mapping individual classes to separate database tables may be simple, however, if a class
structure is more complex, then mapping must be carefully considered to allow data to be
represented and accessed as efficiently as possible.

Object-relational mapping basically manages the translation of objects into relational databases, and
vice versa. It answers questions of how object-oriented constructs like inheritance, aggregation, or
relations can be mapped to the semantics of a relational database.

1. Foreign Key Mapping (one-to-many)

Maps an association between objects to a foreign

key reference between tables.

<- an album can have many tracks. Multivalued

attributes are moved to a separate table.

To implement one-to-many relationships, you

simply have to include the key of one table in the
other table.

25
 260CT Notes
Salman Fazal

2. Association Table Mapping (many-to-many)

Saves an association as a table with

foreign keys to the tables that are linked
by the association. Works as a
junction/linking table.

To implement many-to-many
relationships, you simply create a table
that just contains IDs of foreign keys of
two tables.

3. Mapping Inheritance

Relational databases dont support inheritance, here are some ways of mapping inheritance:

a) Single Table Inheritance

Uses one table to store all

classes in a hierarchy, with the
ability to identify individual
types.

<- include the type attribute

b) Class Table Inheritance

Uses one table for each class

in a hierarchy.

26
 260CT Notes
Salman Fazal

c) Concrete Table Inheritance

Uses one table to store each

concrete class in a hierarchy.

Each table contains field

from concrete class and all
its super-classes.

COMPARISON:

Advantages
Single Table - Easier modifications
- Avoid joins (as all in one table)
Class Table - no attribute duplication (unlike
the other two methods)
- no wasted/null fields
Concrete - Avoid joins (allowing objects to be
Table pulled of a single table)
Disadvantages
- Wasted space (as each row has all possible
subtypes leading to empty columns)
- large size of table with lots of indexes
- Needs multiple joins to load a single object
reduces performance.
- inflexible to changes (all tables are
required to be altered if a change in
superclass)

DATA MANAGEMENT CLASSES

Two methods to data management:

a) PersistentObject: allow all persistent objects to inherit from a PersistentObject class.

b) Data Broker classes: database broker approach, use data storage classes to manage objects.

Persistent Object Approach (direct mapping)

- The persistent Object approach means that individual data classes have to deal with mapping
objects to and from the database

- Create an abstract superclass (PersistentObject) and make all persistent classes inherit from it.

- One PersistentObject to all classes: very strong coupling all data classes at a utility class.
However, these data classes have poor separation of concerns (low cohesion) and thus difficult
to reuse.

27
 260CT Notes
Salman Fazal

The PersistentObject class will have methods to

store, delete and update data to and from the
database.

The write and read methods are called by the

store, delete and update methods to:

- Break objects into attributes and write them

to a database
- Read the attributes back and reconstruct an
object.

The write and read methods basically read/write

to a file or database, they are abstract meaning
their method bodies are not implemented in the
superclass. Different persistent classes (i.e.
patient, appointment, dentist, etc) require
different implementation, therefore the method bodies are defined in the data class.

Data Brokers Approach (indirect mapping)

In this approach, there is a good separation of concerns (higher cohesion and lower coupling). All the
persistence related methods are in the broker classes and are not visible to the data classes.

o Separates data objects from the data storage classes

o An associated broker class is required for each data class.
o The broker class provide mechanisms to materialise objects from the database and
dematerialise them back.

Example:

PatientBroker is
responsible for the
storage and retrieval
of Patient object
instances.

Data Access Object Pattern

DAO is used to separate low level accessing operations from high level business services. The idea is
that instead of having the domain logic communicate with the database or any other persistent
storage, the domain logic speaks to the DAO instead, which then communicates the database.

It is an object/interface, which is used to access/manipulate data from database of data storage.

The advantage of this layer is, ifyou need to make a change to the persistence mechanism, you only
change it in the DAO layer and not all the places in the domain layer where the DAO is used from.

28
 260CT Notes
Salman Fazal

The DAO Pattern consist of the following:

Data Access Object Interface: this interface defines the operations to be performed on a
model object(s).
Data Access Object concrete class: this class implements the above interface. It is
responsible for retrieving data from the data source.
Model Object: this object contains get/set methods to store data retrieved using the above
DAO class.

Example:

- The Student acts as a model.

- The StudentDao is the DAO

interface.

- The StudentDaoImpl is a class

implementing the interface.

Repository Design pattern

The repository pattern is similar to DAO. It separates the business logic from the data access logic,
improving the codes maintainability and readability.

The repository mediates between

the data source layer and the
business layers of the application.

The repository queries the data

source for the data, maps the
data from the data source to a
business entity.
The repository persists changes in the business entity to the data source.

(In MVC, the repository is between the Controller and the Model)

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

__________________________________________________________________________________

29
 260CT Notes
Salman Fazal

Anti-Design Patterns
Anti-design patterns are contrary to design patterns; programming practices that create problems
instead of solving them, they are considered bad programming practice.

Blob Anti-Pattern

- A single class with a large number of attributes/operations

- A collection of unrelated attributes and operations in a single class
- A single controller control almost then entire application
- The class is too complex to reuse and to modify without affecting other classes.

Exam Topics
Week 1

Agile (Scrum Extreme Programming)

Functional & Non-functional Requirements
Forward, Reverse, Round-Trip & Re-Engineering

Week 2

3/4 Tier Architecture

MVC

Week 3

Design Patterns

Week 4

GoF Patterns

Week 5

Data Mapping Patterns

Week 6

Anti-Design Patterns

30