Software High-Level Design and Modeling

In Chapter 4, we covered requirement management, gathering, specification, use cases, and software design from requirement specifications.

Chapter 5 focuses on:

Software high-level design
Software architecture patterns
Software architecture
Software design patterns
Software component design
High-level software design technological considerations

5.1 Introduction

After conducting a feasibility study, gathering requirements, and preparing requirement specifications, the next step is to consider implementation details. The implementation details should outline the procedure for creating a software product design that meets the functional and nonfunctional requirements, while also considering cost-effective and quick technology implementation.

The implementation should consider the system model, system structure, component design, incorporation of product features to fulfill requirement specifications and data flow within the system.

5.2 Design Patterns

Another design consideration is the use of templates to build similar components from a single template. Design patterns reuse existing expertise in well-defined templates instead of designing from scratch, which is heavily utilized in software product development.

5.3 Software Model Levels

The software model exists at three levels:

Top-Level (Architecture Pattern): Horizontal breakdown into tiers (user interface, middle tier, back-end tier).
Middle-Level (Software Component Design): Vertical division of each tier into components; division can be based on component design patterns.
Bottom-Level (Software Detailed Design): Creation of classes and their members (methods and variables).

5.4 Technology Considerations

Selecting compatible technologies for databases, business logic, and user interfaces is crucial. Software designs are inherently complex, posing two fundamental challenges:

Requires imagination and creativity to translate detailed software requirement specifications into a corresponding software design.
Demands mechanisms to simplify complexity, making it easier for developers to implement and reducing software bugs.

5.5 Importance of Simplicity

Planning the implementation of requirements into a good and simple design is vital. Even in agile methodologies, a high-level software design is necessary to provide a framework for the entire product.

5.6 Chapter Organization

Software architecture: Software design at the highest level, such as a tiered architecture (user interface, middle tier, and back end).
Software component design: Software design at the component level, such as components within the middle tier.
Technologies and programming languages: Their selection affects overall software design, necessitating understanding of related considerations.

5.7 Terminology

Software tiers and layers are used interchangeably to denote the separation/division of software architecture into logical, manageable parts.

Software architecture: Software design at the highest level (e.g., user interface, middle layer, database layer).
Software component design: Software design at a level lower than software architecture. Layers are broken down into software components.
Software detailed design: The third level, below software component design, used to build classes and objects from software components.

5.8 Modeling Languages

Modeling languages are used to model software products. Unified Modeling Language (UML) is the most commonly used language.

5.9 Software Development Methodologies Influence

The software engineering methodology influences the technologies used. Some products need incremental development, making certain technologies more suitable.

5.9.1 Rational Unified Process (RUP)

In RUP, requirements evolve, necessitating design changes. Object-oriented design (OOD) facilitates easier changes compared to other technologies, making it suitable for RUP-based projects.

5.9.2 Incremental Iterative Methodologies

OOD is also suitable for incremental product development. Partial product designs can be prepared initially for projects using methodologies like XP or Scrum. Refactoring allows integration of new features as the product grows.

5.9.3 Waterfall Methodology

The Waterfall model requires a complete design at the project's outset with provisions for future changes. Almost all programming and designing methods work well with it. Knowing the time required for software design in advance is crucial for project planning and cost estimation.

5.10 Reducing Complexity in Software Design

Dividing the design into manageable parts is key, done at two levels:

Breaking down the design into layers (user interface, business logic, database) using software architecture patterns.
Breaking down each layer into smaller modular parts using software design patterns. Modularity is key.

A best practice is designing software parts into modular components, hiding implementation details, and exposing only necessary integration details.

User interfaces, middle layers, and database layers each can be broken down into components:

User Interface: User interface components (windows, textboxes), client-side scripts, client-side validations.
Middle Layer: Components (Component 1, Component 2, etc.) broken into classes and server-side scripts.
Database Layer: Schemas, tables, columns, and other database entities.

The division into layers increases productivity and promotes specialization. Common layers are user interface, business logic, and database, with occasional additional layers like the presentation layer.

A user interface can be based on a simple model-view architecture. The middle layer processes user input, and the output is displayed on the user interface, potentially using a controller like Model-View-Controller.

The middle (business logic) layer benefits from modular design using object-oriented programming. Smaller classes are generally better for maintainability. Database layer design requires careful entity-relationship diagram creation and database table normalization.

5.11 Logical Design for Software Architecture

Software layers/components can be physically separated across computers. User interface, business logic, and databases can reside on the same or different computers based on load balancing, performance, and user preferences.

Logical designs simplify software design for deployments across physically separated computers, capturing essential design elements while hiding physical locations.

5.12 Architecture Design Patterns

Some software products are monolithic without layers, which are suitable for small software products. However, many are large and need scalable designs with separation of concerns.

Common layers in commercial systems are user interface, business logic, and database. Integration with other software products may add more layers.

Dividing software architecture into layers follows software architecture patterns, which are templates to break designs into parts. Examples include web-based architecture patterns and three-tier architecture templates.

Other architecture patterns include event-driven, rule-based, and pipes and filters. Multi-tier architecture patterns are widely used.

5.12.1 Two-Tier Architecture Pattern

Business logic and user interface reside on the same logical layer with the database separate. Suitable for small software products.

Two-tier client-server and web-based architectures differ significantly. Web-based architectures involve user access via a browser, with applications running on a server combining web and application servers to handle static and dynamic content, business logic, and database interaction.

5.12.2 Three-Tier Architecture Pattern

User interface, business logic, and database are separate layers in a web-based or client-server architecture.

This is the most common type of software product architecture. Websites require web servers, application servers, and databases. The physical arrangement of layers depends on hardware configuration.

Users access the website via a URL, triggering the web server. Interactions invoke business logic on the application server, which processes commands and accesses the database. Data is processed and sent back through the application and web servers to the user's browser.

This architecture separates the presentation layer, business logic, and database, enabling parallel development and specialization.

5.12.3 n-Tier Architecture Pattern

Used when integrating with other software products, resulting in multiple layers. Can be client-server or web-based.

5.13 Client-Server Architecture

Involves a server and many consoles. One computer acts as a server, the other as a client.

Software is divided into client and server parts, termed front end and back end. Front-end design involves programs installed on client computers, mainly user interface design, but may include some business logic. Most processing occurs on servers.

Client-server architecture uses operating system-dependent programs. It is an implementation of an n-tier architecture pattern. Its usage is declining since the advent of the Internet and the World Wide Web (WWW).

5.14 Web-Based Architecture

Websites have become popular. Users can visit websites and access products or services. Most websites have static and dynamic content, the latter generally created using business logic and database connections.

Web architecture differs from client-server. Users access the website using a browser, with content hosted on a web server. The web server keeps static content and can generate dynamic content using client-side scripting. The application server can also generate dynamic content, running server-side scripts or compiled code.

The architecture concludes with a database holding permanent data. The web browser displays content from both the web server and client-side scripts. A web server hosts HTML content and can display static content. Client-side scripts run on the user's browser. Application servers run server-side scripts and programs, accessing the database as needed and sending content to the web server.

The Web server combines static content with the content coming from the Application server before sending the combined contents to a Web browser.

5.14.1 Web Browser

Web browsers (e.g., Microsoft Internet Explorer, Mozilla Firefox) display content in HTML format. They have a URL text field. Users type the URL of a web page, and the content becomes displayed on the user's web browser.

5.14.2 Web Server

Web servers host websites and their pages, hosting multiple websites. When a user points their browser to a URL, the browser downloads the default web page located at the website.

Static content is displayed in formatted HTML. Client-side scripts perform utilities, such as maintaining user information through cookies. JavaScript and Python are commonly used for writing client-side scripts.

5.14.3 Application Server

Application servers store server-side scripts and compiled codes called through URLs at the user browser. Server-side scripts output should be compatible with HTML syntax.

Application servers can also host compiled code, such as Java Servlets. Technologies include PHP, ASP, .Net, and JSP. Choosing the right application server is based on a selection of a scripting language.

5.14.4 Benefits of Web-Based Architecture

Web-based architecture has overcome problems associated with client-server architecture. It has eliminated the need to install client software on each user machine.

Web browsers are sophisticated and can do all the tasks that are required by the client in any software product. Web browsers connect with any website because the content that goes to the browser from any web server is in HTML format. Thus, they are platform-independent.

Another benefit with web-based architecture is that you can deploy a web-based product on a company’s intranet if it is not required to be deployed over the Internet. Because of these benefits, web-based architecture has replaced the legacy client–server architecture in almost all software products.

5.15 Service-Oriented Architecture

Service-Oriented Architecture (SOA) involves components or products developed to be used by other vendors. One software product acts as a service provider, while another acts as a service consumer.

SOA products are deployed over the Internet and are also known as web services. Consumers can integrate with SOA products through open interfaces, making them platform or vendor independent.

An SOA product has its software services available through an open interface. A software product that depends on SOA architecture (whether a consumer of SOA services or a provider of SOA services) has a distinctly different architecture when compared to the software products that do not depend on SOA services. If your software product is a consumer of SOA services, then you will have to consider an n-tier architecture because one tier of your software product will be exclusively used by an SOA service provider. Specific details of SOA are out of the scope of this book.

5.16 Software Component Design Fundamentals

A software system can be modeled through the use of components. The attributes and behavior will be contained within its boundaries and will be accessible only through the integration considerations. Component design for user interfaces is out of the scope of this book. Here, we discuss component design for the middle layer (i.e., the business logic layer) only.

5.16.1 Component Modeling Considerations

Compatibility: Components can be replaced with equivalent components without affecting system functionality. A new component can either be built or purchased, if its specifications are well defined and match the requirements.
Abstraction: Grouping similar (but not identical) components together. A master component is first created, and then other similar components are created from it.
Refinement: Segregating dissimilar things.
Modularity: Dividing the software product design into many components that can be managed individually without affecting the other components.
Data Structure: A representation of the logical relationship between the individual elements of data.
Information Hiding: Components should be designed in such a way that the information contained within one is not available to other components that have nothing to do with that information.

5.17 Component Diagrams

UML diagrams represent the structure of the system and are useful for documenting the architecture of software systems. UML is used to draw these diagrams. They show the software components and their connections. Tight vs. Loose couplings can be shown.

Component-based development is based on the idea that the previously developed components can be reused and, if necessary, those components could be replaced by other equivalent components. OOD heavily uses component diagrams.

5.17.1 Component Example

To translate the use cases into component design, we need to recall what the use cases were depicting about the interaction between the user and the system. Then, we have to think of how the use cases will help in building the software components.

5.18 Data Flow Diagram

A data flow diagram depicts how the data flow from one component to another (in a software system) during data processing when a user or another software component interacts with a component.

A data flow diagram deals with how the data flow in a system. It specifies things such as where the data are coming from, where will they go, and where will they be stored.

A data flow diagram consists of three elements: process, external entity, and data store.

5.18.1 Data Flow Example

In most cases, a data flow is initiated by an external entity. The software system processes and transforms the data. Finally, the data are saved in a data store.

5.19 Software Design Patterns

Software design patterns are similar concepts to software architecture patterns with the purpose of solving problems at a more minute level. Software design patterns are applied at class and object levels in OOD. Software design patterns are a great way to design the required classes and objects. A software design pattern is a template for designing the classes.
Software design patterns have been created based on the experience of the people who have worked in creating classes for various purposes.

5.19.1 Difference between a Class and a Component

Software design patterns are about grouping of classes in various patterns. An interface class together with those two implemented classes can be called a component.

5.19.2 Software Design Pattern Types

Software design patterns are primarily divided into three types: creational design patterns, behavioral design patterns, and structural design patterns.

5.19.3 Creational Design Patterns

Creational design patterns are used to control how the child classes are created from the parent classes. During runtime, it is also possible to control how and when the objects can be created such as abstract factory, builder method, factory method, object pool, prototypes, and singleton.

5.19.3.1 Abstract Factory

The abstract factory design pattern is used to create concrete classes from abstract classes that are totally encapsulated from each other.

5.19.3.2 Builder

The builder design pattern is used when you need to create many objects (during runtime) that are related to a single parent object.

5.19.3.3 Factory Method

The factory method is used when a new operation needs to be taken care of.

5.19.4 Structural Design Patterns

Structural design patterns are used for managing the interfaces of the objects to control their integration with other objects during runtime. Some of the design patterns related to the structural design patterns include adapter, bridge, composite, decorator, façade, flyweight, private class data, and proxy.

5.19.4.1 Adapter

The adapter design pattern is used to create backward compatibility such that the older releases of a software product still works with the new releases..

5.19.4.2 Proxy

A proxy design pattern is used where an object needs to be replaced by another object during runtime.

5.19.5 Behavioral Design Patterns

Behavioral design patterns are used to control the behavior of the classes so that the objects created from those classes can interact with each other properly. Some of the design patterns belonging to behavioral design patterns include chain of responsibility, command, interpreter, iterator, mediator, and memento.

5.19.5.1 Command

The command design pattern is used to pass a command from one object to another so that some computation or another command can be generated.

5.19.5.2 Iterator

The iterator design pattern can be used when the user needs to evaluate some options before selecting one of them

5.20 Programming Language Considerations

In the previous sections, we have seen how a software product is modeled based on the given requirements. We also need to consider how the model of a software product can be implemented when the technology considerations are given.

From a purely business point of view, the technology that provides the best productivity and thus saves time and money is the best one to choose for product development. Let us see how the factors influence implementation details. These technological factors includes; size of software product, type of software product, technologies available in the market, code reuse and considerations for nonfunctional requirements.

5.20.1 Size of Software Product

Not all technologies scale well. For example, Microsoft Access is a database well suited for building small software products. If a proposed software product will be used by just a few users, then choose the technologies that will allow the rapid development of the product using the least amount of skill and money.

5.20.2 Type of Software Product

Each industry has a different kind of need for software products. For example, if you are building a software product for children’s games, then you do not need to build the security components for that software product. On the other hand, security components are the most crucial components for building software products for the defense industry.

5.20.3 Technology Availability

If you want to develop a software product, there is a plethora of technologies available to choose for this purpose.

5.20.3.1 Integrated Development Environment Infrastructure

The infrastructure includes compilers, database connectors, application servers, debuggers, configuration management servers and other components that are part of an Integrated Development Environment (IDE).

5.20.3.2 Platform Independence

If a programmer uses the libraries provided by an operating system, then his or her code will run only on that operating system

5.20.3.3 Library Infrastructure

Libraries help provide an infrastructure that programmers can use while writing their source code.

5.20.4 Code Reuse

There is already an existing code available in the form of a large number of software products in the market. If the software product you are developing involves a large number of software components that have similar functionality, then it is possible to reuse those components.

OOD especially helps in reusing the source code because it is possible to abstract the design consideration of all similar components and then use a common interface or abstract class to derive all the classes in your product.

5.21 Types of Programming Languages: A Brief Review

Another high-level design decision in developing a software product is the selection of programming language. There are many programming languages, which have their own benefits and shortcomings. Programming languages can be divided into two different types, imperative and declarative, based on the way in which we can write the code using the programming languages. Some programming languages are developed to do special tasks. For example, there are programming languages developed for scripting on web pages.

5.22 Security

A top-priority nonfunctional requirement for web-based software products is security.

5.22.1 Authorization

Any system can be secured by providing access to authorized people only.

5.22.2 Role-Based Security

Used by people whose roles are well defined by their companies. We can define the roles and attach them with the specific functionalities of the software product.

5.22.3 Security Based on the User Data

A user can only view and perform the transactions that are applicable to the data of that user ID.

5.22.4 Data Encryption

Encryption is the process of converting information from its original form to another form so that it cannot be easily interpreted by anyone except the designated user(s) of that information.

5.23 Performance

Web-based software products are accessed by the users through the Internet. Connection speed greatly determines the performance of any website.

From a software design aspect, some of the factors that affect the performance of a system include the following:

Large software components take a long time to read or load (depending on whether they are read on the client side or the server side). Therefore, always keep the component size of your software products as small as possible.
Connecting to the database is a time-consuming process. If your source code connects too often to the database, then the response time from the system will be long and the user has to simply wait for the response.
Do not use images or blobs (objects) that are large in size. Loading them on a user browser will take more time.

5.24 Case Study

OBAAS will be a web-based software product. Users can access the software product using a browser. OBAAS will be deployed on a web server having an application server as well. There will be a database at the back end to store the permanent transaction data.

5.24.1 Three-Tier Architecture

The three-tier architecture will give us an opportunity to use the client-side scripts, the server-side scripts, an executable server code, and a database connection. This architecture will be flexible and we can choose any database or any application server.

5.24.2 User Interface

A user interface will be built for web browsers. The web pages are built using HTML. Client-side scripts are used for user input validation.

5.24.3 Middle Layer

The middle layer will be composed of server-side scripts written on each web page. There will be some executable compiled binary code on the application server that will be called from the server-side scripts written on each web page.

5.24.4 Database

The Oracle database has been used for OBAAS 1.1 and OBAAS 1.2.

5.24.5 Component Diagram

For web-based software products, a web page can be considered a component. We have also seen the use cases for it. On the basis of the use cases, the component diagram for OBAAS is made.

5.24.6 Data Flow Diagram

The user (customer) initiates all the transactions (processes). The bill payment process updates the account data store. The account balance process accesses the account data store to display the account balance of the customer.

5.24.7 Code Reuse

For OBAAS 1.2, we will be using the same code base of OBAAS 1.1. The changed functionality of cheque request will be achieved by adapting the cheque request component using refactoring.

5.24.8 Maintainability

We will use an object-oriented programming language and create the classes that can be maintained. We will use a modular design so that it is easier to maintain our software product.

5.24.9 Security

To ensure that the database connection information is secured, we will keep the database connection string information only within the executable server code. In addition, as a basic security measure, when the user enters characters in the password field, OBAAS will not show the actual characters. Instead, it will show asterisks.

5.24.10 Performance

To guarantee good performance by OBAAS, we will not use large images or videos and we will use an executable server code to connect to the database.

5.24.11 Methodology

Our technology (i.e., three-tier architecture and object-oriented programming and design) allows us to work using any software engineering methodology.