260CT Revision Notes

Short Notes By: Salman Fazal

Contents SE Overview

……….…………………………………………………………….

1

(Objectives, Principles, Methodologies)

Architectural Design patterns GRASP

……………………………………………

8

………………………………………………………………………………

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 systematic and organised development of highquality software systems within cost, time and other constraints. 2

It’s a discipline that is concerned with all aspects of software production, including; o o o

Software development process Project Management Tools, methods and theories adopted

Validation – Test if the product is specified to the user’s 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 ” “ Divide ” 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, don’t 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 al ready discovered a solution, think again…but 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


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 fo rm. -

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


Software Application Architecture - The process of defining a structured solution that meets all of the technical and operational requirements. - Involves optimizing common quality attr ibutes 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, c lient 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) Ti er and Database Tier

8


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 it’s 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 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 a nd 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 inc ludes 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


MVC ARCHITECTURE

Model – –view –controller (MVC) is a software design pattern for implementing user interfaces on computers. It divides a given software sof tware 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


GRASP (Design Pattern) Pattern – A principle used that provide guidance in the creation of software. Have a name, problem description and problem solution. repeatable solution to a commonly occurring problem in software Design Pattern – a general repeatable 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

o

Architectural Patterns – Presenting an essential structural schema for a software system. E.g. MVC 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 object‐oriented design principles related to creating responsibilities for classes and defining objects. Grasp Patters: Controller, creator, indirection, information expert, high cohesion, low coupling, polymorphism, don’t 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 | ------------------| checkEmail() | | sendEmail() | | emailValidate() | | PrintLetter() | -------------------

---------------------------| Staff | ---------------------------| -salary | | -emailAddr | ---------------------------| setSalary(newSa setSalary(newSalary) lary) | | getSalary() | | setEmailAddr(ne setEmailAddr(newEmail) wEmail) | | 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 ‘ 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: -

Façade 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.

*Façade is suitable when there are ar e no too many events, however it’s 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


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: Who’s 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 c reate pluggable software components? (Replace one component without affecting the main component). Solution: Use polymorphism to assign responsibilities on classes when the behaviour changes.

14


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 doesn’t 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 Don’t talk to strangers. “Each class should only talk to its friends (close ones)”

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

The this object (or self). A parameter of the method. An attribute of this. An element of a collection which is an attribute of this. An object created within the method.

Notes ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ _______________________ ___________________________________ ______________________ ______________________ ______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ _______________________ ___________________________________ ________________________ _______________________ ______________________ ______________________ _____________ __ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ______________________________________ ___________________________ _______________________ _______________________ _____________________ __________ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ __________________________ _________________________ ______________________ ______________________ ____________ 16


OO Design and Principles

ABSTRACTION The developer and other objects in the system have a high-level summary view (an abstract v iew) 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


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


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


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)_____________ time)_____________ Override – child class provides alternate implementation for the parent class method (r untime)____ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ _______________________ ___________________________________ ______________________ ______________________ _______________________ _______________________ ______________ __ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ ______________________ ___________________________________ ______________________ ______________________ _______________________ ______________________ _______________ ___ _______________________ ___________________________________ _______________________ ______________________ _______________________ _______________________ _____________ __

20


‘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. classes and objects are connected together to build Structural patterns – describes how classes 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 o n 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 they’re 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, it’s 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 c reated and pointed to the huge size memory co nsuming object for further processing. Example a real image contains a huge size data which clients needs to access. o Solution: o 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 o n a different system can represent the RealImage in the new system.  



23


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 o ne 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


Data Mapping & Patterns Layered architecture review:

Data Persistence in OO: Transient Data/Object (temporary data): 1. Stored in the computers RAM. When a program completes, the data is de-allocated. de -allocated. Persistent Data/Object (permanent data): 2. 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 c lass 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) ( 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 don’t 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


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 - Avoid joins (allowing objects to be pulled of a single table)

Concrete 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 wr ite them to a database Read the attributes back and reconstruct an object. The write and read methods basically r ead/write to a file or database, they are abstract meaning their method bodies are not implemented i mplemented 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 l ower coupling). All the persistence related methods are in the broker cl asses and are not visible to the data classes. o o o

Separates data objects from the data storage classes An associated broker class is required for each data class. 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 al l 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 code’s 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


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

260CT Revision Notes

Recommend Documents