ESE Software Architecture

Architectural decisions are those that permit a system to meet its quality attributes and behavioral requirements.

Architectural decisions are all about design constraints intended to guarantee certain global requirements. Typically these are non-functional requirements having to do with performance, scalability, maintenance, and so on.

The architecture of a system consists of:

1. the structure(s) of its parts
e.g. design-time, test-time, and run-time software and hardware parts

2. the externally visible properties of those parts e.g. interfaces of modules, hardware units, objects

3. the relationships and constraints between them

A subsystem is a system in its own right whose operation is independent of the services provided by other sub- systems.

A module is a system component that provides services to other modules but would not normally be considered as a  separate system.

A component is an independently deliverable unit of software that encapsulates its design and implementation and offers interfaces to the out-side, by which it may be composed with other components to form a larger whole.

Cohesion is a measure of how well the parts of a component “belong together”.

• Cohesion is weak if elements are bundled simply because they perform similar or related functions (e.g., java.lang.Math).

• Cohesion is strong if all parts are needed for the functioning of other parts (e.g. java.lang.String).

• Strong cohesion promotes maintainability and adaptability by limiting the scope of changes to small numbers of components.

Coupling is a measure of the strength of the interconnections between system components.

• Coupling is tight between components if they depend heavily on one another, (e.g., there is a lot of communication between them).

• Coupling is loose if there are few dependencies between components.

  —Loose coupling promotes maintainability and adaptability since changes in one component are less likely to affect others.

  —Loose coupling increases the chances of reusability.

In a more object-oriented design, each subsystem is responsible for its own data. Subsystems talk to each other only through a defined API. Changes to the data representation only affect a single subsystem. Changes to a subsystem’s API affect only client subsystems.

an architectural style defines what kinds of components exist in a software system, and how these components interact.

A layered architecture organises a system into a set of

layers each of which provide a set of services to the layer “above”.

> Normally layers are constrained so elements only see —other elements in the same layer, or
—elements of the layer below

> Callbacks may be used to communicate to higher layers

> Supports the incremental development of sub-systems in different layers.

—When a layer interface changes, only the adjacent layer is affected

The components of this style are layers.
The constraint is that each layer only sees the layer immediately

below it.
The desirable property is that changes to the interface of a layer

will only impact the layer above.

One affected quality attribute is maintainability: it becomes cheap to replace or reuse an entire layer. Changes to a layer have limited impact. (What other quality attributes might be affected? Scalability? performance? ...)

Bsp: OSI Model

A client-server architecture distributes application logic and services respectively to a number of client and server sub-systems, each potentially running on a different machine and communicating through the network (e.g, by RPC).

The components here are the clients and the servers. The constraints are that clients are responsible for interaction with users, servers are responsible for services, and clients make requests to servers to get obtain these services.

The nice properties are low coupling (between client and server) and high cohesion (each has its own responsibilities). This is good for maintenance, but can also impact scalability and performance.

Advantages

• Distribution of data is straightforward
• Makes effective use of networked systems. May require cheaper hardware
• Easy to add new servers or upgrade existing servers

Disadvantages

• No shared data model so sub-systems use different data organization. Data interchange may be inefficient
• Redundant management in each server
• May require a central registry of names and services - it may be hard to find out what servers and services are available

In a fat client architecture, the server only provides computational services and the client takes care of the rest (UI, input validation, presentation updates)

—good for responsiveness; places more constraints on users

In a thin client architecture the client only acts as a presentation engine, and the server does everything else

—good for low-cost clients; impacts latency

Early (Web 1.0) web applications are thin clients: the client is just a web browser, and every single click requires the server to generate a new web page.

Web 2.0 applications are essentially fat clients that make heavy use of JavaScript to do much more work in the browser. As a result many requests can be fulfilled without contacting the server at all. This decreases the load on the server and gives the end-user a more responsive experience. On the other hand, it places a greater burden on the client, assuming the existence of a modern web browser.

This is a well-established, generic architectural style for business application.

A four-tier architecture distinguishes:

1.the client GUI (fat or thin)
2.the web service
3.business objects providing business logic
4.a mainframe legacy application or database system

• The extreme generalization of Client-Server
• Instead of monolithic systems one has many concise services
• A Service is a “loosely coupled, reusable software component, which can be distributed”
• Services use message-based communication
• Service discovery becomes a challenge

Inspired from the architecture of the largest distributed application ever: the Web

— Stateless requests
— Every resource has an individual URI
— Uniform interface for all resources (GET, POST, PUT, DELETE)

The structure of a response is not specified

By being stateless, REST improves performance, scalability, portability and reliability

A repository architecture distributes application logic to a number of independent sub-systems, but manages all data in a single, shared repository.

Google docs is an instance of a repository architecture. Your docs are always in the cloud.

When looking at the picture, think Eclipse. Notice that cohesion is strong, as each subsystem has its own clear responsibilities. However the repository is strongly coupled to all other subsystems. Sharing of data is maximized, but the repository format can only be changed at the risk of impacting all other components.

Advantages

• Efficient way to share large amounts of data
• Sub-systems need not be concerned with how data is produced, backed up etc.
• Sharing model is published as the repository schema

Disadvantages

• Sub-systems must agree on a repository data model
• Data evolution is difficult and expensive (unless NoSQL)
• Repository can become performance bottleneck

• A method of storing data across multiple machines
  • reduces processing needs
  • reduces storage needs
• Queries must be routed to the corresponding shards

In an event-driven architecture components perform services in reaction to external events generated by other components.

• In broadcast models an event is broadcast to all sub-systems. Any sub-system which can handle the event may do so.
• In interrupt-driven models real-time interrupts are detected by an interrupt handler and passed to some other component for processing.

Such event-driven systems scale well due to extremely low coupling between components.

This architectural style will become increasingly relevant with the advent of multi-core machines due to asynchronous communication (events are distributed without requiring a call and response).

Effective in integrating sub-systems on different computers in a network

Can be implemented using a publisher-subscriber pattern:

• Sub-systems register an interest in specific events
• When these occur, control is transferred to the subscribed sub- systems

However, sub-systems don’t know if or when an event will be handled

In a dataflow architecture each component performs functional transformations on its inputs to produce outputs.

> Highly effective for reducing latency in parallel or distributed systems

—No call/reply overhead
—But, fast processes must wait for slower ones

Not really suitable for interactive systems

—Dataflows should be free of cycles

good for videos or stock markets etc.