Architecture: Modeling & Designing Software Projects Architecture

When I model and design the architecture of software project, first thing I consider is what is the software project type?

My experience in this field of projects architecture has taught me that most applications fails into seven software types, each type has its own technology's, communication patterns, architectural patterns and design steps.

The software categories are:

1. Object oriented Software:

The object-oriented design uses the concepts of information hiding, classes, and inheritance. This results in the design of a sequential object-oriented software architecture, which would be implemented as a sequential program with one thread of control.

2. Client / Server Software.

In these systems, a client is a requester of services and a server is a provider of services. Typical servers are file servers, database servers, and line printer servers. Client/server architectures are based on client/service architectural patterns, the simplest of which consists of one service and multiple clients. This pattern has several variations, which will be described next. In addition, certain decisions need to be considered about the design of client/server architectures, such as whether the server should be designed as a sequential or concurrent subsystem, what architectural structure patterns to use for the design of the client/server architecture, and what architectural communication patterns to use for interaction between the clients and the services.

Also differentiates between a server and a service. A server is a hardware/ software system that provides one or more services for multiple clients. A service in a client/server system is an application software component that fulfills the needs of multiple clients. Because services execute on servers, there is sometimes confusion between the two terms, and the two terms are sometimes used interchangeably. Sometimes, a server will support just one service or perhaps more than one; on the other hand, a large service might span more than one server node. In client/server systems, the service executes on a fixed server node(s) and the client has a fixed connection to the server.

3. Service-Oriented Architecture.

SOA is a distributed software architecture that consists of multiple autonomous services. The services are distributed such that they can execute on different nodes with different service providers. With a SOA, the goal is to develop software applications that are composed of distributed services, such that individual services can execute on different platforms and be implemented in different languages. Standard protocols are provided to allow services to communicate with each other and to exchange information. In order to allow applications to discover and communicate with services, each service has a service description; the service description defines the name of the service, the location of the service, and its data exchange requirements.

A service provider supports services used by multiple clients. Usually, a client will sign up for a service provided by a service provider, such as an Internet, email, or Voice over Internet Protocol (VoIP) service. Unlike client/server architectures, in which a client communicates with a specific service provided on a fixed server configuration, this chapter describes SOAs, which build on the concept of loosely coupled services that can be discovered and linked to by clients (also referred to as service consumers or service requesters) with the assistance of service brokers. This document describes how to design SOAs, how to design services, and how to reuse services.

4. Distributed Component-Based Software.

In the design of software architectures for a distributed component-based software design; the component-based software architecture for the distributed application is developed. The software application is structured into components, and the interfaces between the components are defined. To assist with this process, guidelines are provided for determining the components. Components are designed to be configurable so that each component instance can be deployed to a different node in a geographically distributed environment.

Components are initially designed using the subsystem structuring criteria. Additional component configuration criteria are used to ensure that components are indeed configurable – in other words, that they can be effectively deployed to distributed physical nodes in a distributed environment.

5. Concurrent Real-Time Software.

The real-time software is a concurrent architecture usually, having to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control.

Real-time software architectures are concurrent architectures that usually have to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control. Thus, the design of finite state machines, state-dependent interaction modeling, and the control patterns, are very important in the design of real-time software architectures.

6. Software Product Line.

It is architectures for families of products that need to capture both the commonality and variability in the family.

A software product line (SPL) consists of a family of software systems that have some common functionality and some variable. Software product line engineering involves developing the requirements, architecture, and component implementations for a family of systems, from which products (family members) are derived and configured.

The problems of developing individual software systems are scaled upwards when developing SPLs because of the increased complexity due to variability management.

As with single systems, a better understanding of a SPL can be obtained by considering the multiple views, such as requirements models, static models, and dynamic models of the product line. A graphical modeling language such as UML helps in developing, understanding, and communicating the different views. A key view in the multiple views of a SPL is the feature modeling view. The feature model is crucial for managing variability and product derivation because it describes the product line requirements in terms of commonality and variability, and defines the product line dependencies. Furthermore, it is desirable to have a development approach that promotes software evolution, such that original development and subsequent maintenance are both treated using feature-driven evolution.

7. Framework Software.

A software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API). It is a universal, reusable software platform used to develop applications, products and solutions.

Software Frameworks include support programs, compilers, code libraries, an application programming interface (API) and tool sets that bring together all the different components to enable development of a project or solution.

Frameworks contain key distinguishing features that separate them from normal libraries:

7.1. Inversion of control - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.

7.2. Default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.

7.3. Extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.

7.4. Non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.

-----------------------------------------------------------------------
Last thing is very important should be considered when architecting any project. It is Non-Functional requirements and should be taken into consideration when designing such software types from the modeling and design stage not when implementing the project.

In my architecture document I called it Software quality attributes.

Software quality attributes:

Refer to the nonfunctional requirements of software, which can have a profound effect on the quality of a software product. Many of these attributes can be addressed and evaluated at the time the software architecture is developed. Software quality attributes include maintainability, modifiability, testability, traceability, scalability, reusability, performance, availability, and security.

Some software quality attributes are also system quality attributes because they need both the hardware and software to achieve high quality. Examples of these quality attributes are performance, availability, and security. Other software quality attributes are purely software in nature because they rely entirely on the quality of the software. Examples of these quality attributes are maintainability, modifiability, testability, and traceability.