Sommerville Chapter 6 CSS 506
Software Architecture
Description of how a system is organized. Properties of a system such as performance, security and availability are influenced by the architecture used.
Security
If security is a critical requirement, a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers and a high level of security validation applied to these layers
Availability
If availability is a critical requirement, the architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system. -Fault tolerant system architectures
Maintainability
If maintainability is a critical requirement, the system architecture should be designed using fine-grain, self-constrained components that may readily be changed. Producers of data should be separated from consumers, and shared data structures should be avoided.
Performance
If performance is a critical requirement, the architecture should be designed to localize critical operations within a small number of components, with these components deployed on the same computer rather than distributed across the network. This may mean using a few relatively large components rather than small, finer-grain components. Using large components reduces the number of component communications, as most of the interactions between related system features take place within a component. You may also consider runtime system organizations that allow the system to be replicated and executed on different processors.
Safety
If safety is a critical requirement,the architecture should be designed so that safety-related operations are co-located in a single component or in a small number of components. This reduces the costs and problems of safety validation and may make it possible to provide related protection systems than can safely shut down the system in the event of failure.
Examples of Transaction Processing Systems
Information Systems and resource management systems
Designing overall system architecture in Agile processes
- Generally accepted that an early stage of an agile process should focus on designing an overall system architecture - Incremental development of architectures not usually successful
Natural Language Translator
There will be additional components to the above, such as a dictionary. The output of the system is translation of input text.
Development View
Shows how the software is decomposed for development. That is, it shows the breakdown of the software into components that are implemented by a single developer or development team. -Useful for software managers and programmers
Process View
Shows how, at run-time, the system is composed of interacting processes. -Useful for making judgements about non-functional system characteristics such as performance and availability.
Logical View
Shows the key abstractions in the system as objects or object classes. It should be possible to relate the system requirements to entities in this logical view.
Physical View
Shows the system hardware and how software components are distributed across the processors in the system. -Useful for systems engineers planning a system deployment
Refactoring
- Refactoring components in response to changes is usually relatively easy - Refactoring the system architecture is expensive because you may need to modify most system components to adapt them to the architectural changes
Architectural Model
-High-level, abstract, architectural view of a system that is not cluttered with detail. It identifies the key components that are to be developed. -Can be presented as Box Diagrams
Architectural Model Use
-A good way of supporting communication between the people involved in the software design process as they are intuitive, not cluttered with detail, and relatable. 1. Can be used to focus discussion about the software requirements or design. 2. Alternatively, they may be used to document design o that it can be used as a basis for more detailed design and implementation of the system.
Architectural Description Languages
-A more rigorous notation for architectural description -Used if the architecture of a system is to be documented in more detail
Application Systems
-Are intended to meet a business or an organizational need. Businesses operating in the same sector use common sector specific applications. Consequently, the application systems used by these businesses also have much in common. These commonalities have led to the development of software architectures that describe the structure and organization of particular types of software systems = Application Architectures. -There are many types of application system, and they may seem very different but superficially dissimilar applications may have much in common and thus share an abstract application architecture.
Why is software architecture important?
-Because it affects the performance, robustness, distributability, and maintainability of a system -Individual components implement the functional system requirements, but the dominant influence on the non-functional system characteristics is the system's architecture. -Study shows that non-functional requirements had the most significant effect on the system's architecture.
Reference Architecture
-Capture important features of a system architecture in a domain. They include everything that might be in an application architecture but it's unlikely that any individual application would include all the features shown in a reference architecture. -Main purpose is to evaluate and compare design proposals, and to educate people about architectural characteristics in that domain.
Repository Architecture (text)
-Describes how a set of interacting components can share data. Concerned with static structure of a system and does not show its runtime organization. -The majority of systems that use large amounts of data are organized around a shared database or repository. This model is therefore suited to applications in which data is generated by one component and used by another. ex: command and control systems, management information systems, computer aided design (CAD) systems, and interactive development environments (IDE) for software. -Organizing tools around a repository is an efficient way of sharing large amounts of data. There is no need to transmit data explicitly from one component to another. However, components must operate around an agreed repository data model. Inevitably, this is compromise between the specific needs of each tool, and it may be difficult or impossible to integrate new components if their data models do not fit the agreed schema. -In practice, it may be difficult to distribute the repository over a number of machines. Although it is possible to distribute a logically centralized repository, this involves maintaining multiple copies of data. Keeping these consistent and up to date adds more overhead to the system. -In the repository architecture, the repository is passive and control is the responsibility of the components using the repository. An alternative approach which has been derived for AI systems uses a 'blackboard' model that triggers components when particular data becomes available. This is appropriate when the data in the repository is unstructured. Decisions about which tool is to be activated can only be made when the data has been analyzed.
Repository Architecture (diagram)
-Description: All data in a system is managed in a central repository that is accessible to all system components. Components do not interact directly, only through the repository. -When Used: You should use this pattern when you have a system in which large volumes of information are generated that has to be stored for a long time. You may also use it in data-driven systems where the inclusion of data in the repository triggers an action or tool. -Advantages: Components can be independent, they do not need to know do the existence of other components, changes made by one component can be propagated to all components, all data can be managed consistently (i.e. backups done at the same time) as it is all in one place. -Disadvantages: The repository is a single point of failure so problems in the repository affect the whole system. May be inefficiencies in organizing all communication through the repository. Distributing the repository across several computers may be difficult.
Client-Server Architecture (diagram)
-Description: In this architecture, the system is presented as set of services, with each service delivered by a separate server. Clients are users of these services and access servers to make use of them. -ex: film and video/ DVD library -When Used: Used when data in a shared database has to be accessed from a range of locations. Because servers can be replicated, may also be used when the load on a system is variable. -Advantages: Principle advantage of this model is that servers can be distributed across a network. General functionality (i.e. printing) can be available to all clients and does not need to be implemented by all services. -Disadvantages: Each service is a single point of failure and so is susceptible to denial-of-service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. Management problems may arise if servers are owned by different organizations.
Layered Architecture (diagram)
-Description: Organizes the system into layers, with related functionality associated with each layer. A layer provides services to the layer above it, so the lowest level layers represent core services that are likely to be used throughout the system. - When Used: Used when building new facilities on top of existing systems, when the development is spread across several teams with each team responsible for a layer of functionality, when there is a requirement for multilevel security. -Advantages: Allows replacement of entire layers as long as the interface is maintained. Redundant facilities (i.e. authentication) can be provided in each layer to increase the dependability of the system. -Disadvantages: In practice, providing a clean separation between layers is often difficult, and a high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it. Performance can be a problem because of multiple levels of interpretation of a service request as it is processed at each layer.
System Specification and Reqs Engineering
-Ideally, a system specification should not include any design info. This is unrealistic, except for very small systems. You need to identify the main architectural components as these reflect high-level features of a system. Therefore, as part of the requirements engineering process, you might propose an abstract system architecture where you associate groups of system functions or features with large-scale components or sub-systems. You then use this decomposition to discuss the requirements and more detailed features of the system with stakeholders. - There is significant overlap between the process of requirements engineering and architectural design.
Model-View-Controller (MVC)
-Description: Separates presentation and interaction form the system data. The system is structured into three logical components that interact with each other. The model component manages the system data and associated operations on that data. The view component define and manages how the data is presented to the user. The controller component manages user interaction and passes these interactions to the view and the model. (Separates elements of a system, allowing them to change independently.) -ex: Basis of interaction management in many web-based systems When Used: Used when there are multiple ways to view and interact with data. Also used when the future requirements for interaction and presentation of data are unknown. Advantages: Allows the data to change independently of its representation and vice versa. Supports presentation of the same data in different ways, with changes in one representation shown in all of them. Disadvantages: May involve additional code and code complexity when the data model and interactions are simple.
Pipe and Filter Architecture (diagram)
-Description: The processing of the data in a system is organized so that each processing component (filter) us discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing. -ex: system used for processing invoices -When Used: Commonly used in data-processing applications (both batch and transaction-based) where inputs are processed in separate stages to generate related outputs. -Advantages: Easy to understand and supports transformation reuse. Workflow style matches the structure of many business processes. Evolution by adding transformations is straightforward. Can be implemented as either a sequential or concurrent system. -Disadvantageous: The format for data transfer has to be agreed between communicating transformations. Each transformation must parse its input and unparse its output to the agreed form. This increases system overhead and may mean that it is impossible to reuse architectural components that use incompatible data structures.
Application Architectures
-Encapsulate the principal characteristics of a class of systems. -The application architecture may be re-implemented when developing new systems. However, for many business systems, application architecture reuse is implicit when generic application systems are configured to create a new application. We see this in the widespread use of Enterprise Resource Planning (ERP) systems and off the shelf configurable application systems, such as systems for accounting and stock control. These systems have a standard architecture and components. The components are configured and adapted to create a specific business application. ex: a system for supply chain management can be adapted or different types of suppliers, goods, and contractual arrangements.
Architectural Patterns (style)
-Generally, they are descriptions of system organization that capture the essence of an architecture that has been used in different software systems. The architecture of a software system may be based on a particular architectural pattern. -Think of an architectural pattern as a stylized, abstract description of good practice, which has been tried and tested in different systems and environments. They should describe a system organization that has been successful in previous systems and include information on when it is and is not appropriate to use that pattern, and details on the pattern's strengths and weaknesses. -Patterns may be described in a standard way using a mix of narrative description and diagrams. ex: Model-View-Controller (MVC), Layered Architecture, Repository Architecture, Client-Server Architecture, Pipe and Filter Architecture
Generic Models of Application Systems Architectures
-Help us to understand the operations of applications, compare applications of the same type, validate application system designs, and assess large-scale components for reuse. 1. As a starting point for the architectural design process 2.As a design checklist 3. As a way of organizing the work of the development team 4. As a means of assessing components for reuse 5. As a vocabulary for talking about applications
Layered Architecture (text)
-Here, the system functionality is organized into separate layers, and each layer only relies on the facilities and services offered by the layer immediately beneath it. -Another way of achieving separation and independence. -Layered approach supports the incremental development of systems. As a layer is developed, some of the services provided by that layer may be made available to users. -The architecture is also changeable and portable. If its interface is unchanged, a new layer with extended functionality can replace an existing layer without changing other parts of the system. -When layer interfaces change or new facilities are added to a layer, only the adjacent layer is affected. As layered systems localize machine dependencies, this makes it easier to provide multi-platform implementations of an application system. Only the machine-dependent layers need be re-implemented to take account of the facilities of a different operating system or database. - The number of layers is arbitrary
Client-Server Architecture (text)
-Illustrates a commonly used runtime organization for distributed systems. -A system that follows this pattern is organized as a set of services and associated servers, and clients that access and use the services. The major components of this model are: 1. A set of servers that offer services to other components. 2. A set of clients that call on the services offered by servers. 3. A network that allows the clients to access these services. Client-server systems are usually implemented as distributed systems, connected using Internet protocols. -Are usually thought of as distributed systems architectures but the logical model of independent services running on separate servers can be implemented on a single computer. Again, an important benefit is separation and independence. Service and servers can be changed without affecting other parts of the system. -Most important advantage of this model is that is is a distributed architecture. Effective use can be made of networked systems with many distributed processors. It's easy to add a new server and integrate it with the rest of the system or to upgrade servers transparently without affecting other parts of the system.
Questions system architects must ask
-Is there a generic application architecture that can act as a template for the system that is being designed? -How will the system be distributed across hardware cores or processors? -What architectural organization is best for delivering the non-functional requirements of the system? -How will the structural components in the system be decomposed into sub-components? -etc.
4 + 1 View Model
-Krutchen's model where he suggests that there should be four fundamental architectural views which can be linked through common use cases or scenarios: 1. A Logical View 2. A Process View 3. A Development View 4. A Physical View -During the design process, a conceptual view of the system's architecture is usually made but these views may also be developed when different aspects of the system are discussed. Though, it's rarely necessary to develop a complete description from all perspectives
distributed architecture (decentralized architecture)
-Most large systems are distributed systems in which the system software is distributed across many different computers. The choice of distribution architecture is a key decision that affects the performance and reliability of the system. -For embedded systems and apps designed for personal computers and mobile devices, you don't have to design a distributed architecture for the system.
Who uses architectural models?
-People involved in the software design process -Stakeholders: Useful in communicating with system stakeholders as they can understand and relate to it. -Managers: Useful in project planning as they can start assigning people to plan the development of these systems -Domain experts and software engineers: Useful in helping them to participate in discussions about the system
Non-functional Requirements
-Performance -Security -Safety -Availability -Maintainability
Architectural Patterns Facts
-Proposed in 1990s under the name 'architectural styles'
A LPS can be part of an integrated set of programming support tools.
-The symbol table and syntax tree can act as a central info repository. Tools or tool fragments communicate through it. Other info that is sometimes embedded in tools, such as the grammar definition and the definition of the output format for the program, have been taken out of tools and put into the repository. Therefore, a syntax-directed editor can check that the syntax of a program is correct as it is being typed. A program formatter can create listings of the program that highlight different syntactic elements and are therefore easier to read and understand. (A repository architecture)
Architectural Design Process
-There is no formulaic architectural design process. It depends on the system being developed, the background and experience of the system architect, and the specific requirements of the system. -Consider architectural design a series of decisions to be made rather than a sequence of activities.
Pipe and Filter Architecture (text)
-This is a model of the runtime organization of a system where functional transformations process their inputs and produce outputs. Data flows from one to another and is transformed as it moves through the sequence. Each processing step is implemented as a transform. Input data flows through these transforms until converted to output. The transformations may execute sequentially or in parallel. The data can be processed by each transform item by item or in a single batch. -The name comes from the original Unix system where it was possible to link processing using 'pipes'. These passed a text stream from one process to another. -Systems that conform to this model can be implemented by combining Unix commands, using pipes and the control facilities of the Unix shell. The term 'filter' is used because a transformation 'filters out' the data it can process from its input data stream. -When transformations are sequential with data processed in batches, this pipe and filter architectural model becomes a batch sequential model, a common architecture for data-processing systems such as billing systems. The architecture of an embedded system may also be organized as a process pipeline, with each process executing concurrently.
Box Diagrams
-Used to informally model system architecture -Each box in the diagram represents a component. Boxes within boxes indicate that the component has been decomposed to sub-components. Arrows mean that data and or control signals are passed from component to component in the direction of the arrows. -These diagrams show neither the type of relationships among system components nor the components' externally visible properties
Software architecture can be designed at two levels of abstraction
1. Architecture in the small 2. Architecture in the large
Ways in which the architectural model of a program is used
1. As a way of encouraging discussion about the system design 2. As a way of documenting an architecture that has been designed
General compilers have a generic architecture that includes the following components:
1. Lexical Analyzer: takes input language tokens and converts them into an internal form 2. Symbol Table: hold information about the names of entities (variables, class names, object names, etc.) used in the text that is being translated. 3. Syntax Analyzer: Checks the syntax of the language being translated. It uses a defined grammar of the language and builds a syntax tree 4. Syntax Tree: An internal structure representing the program being compiled. 5. Semantic Analyzer: Uses information from the syntax tree and then symbol table to check the semantic correctness of the input language text. 6. Code Generator: 'Walks" the syntax tree and generates abstract machine code -Other components may be included that analyze and transform the syntax tree to improve efficiency and remove redundancy from the generated machine code.
Explicitly designing and documenting software architecture has 3 advantages
1. Stakeholder communication 2. System analysis 3. Large-scale reuse
Architectural Design
A creative process in which you design a system organization that will satisfy the functional and non-functional requirements of a system. -The notions of separation and independence are fundamental to architectural design because they allow changes to be localized.
Unified Modeling Language (UML)
A general purpose modeling language used in object-oriented software development. -The UML is of most value when you're documenting an architecture in detail or using model-driven development..
Rigorous System Architecture Models
A more detailed and complete description means that there is less scope for misunderstanding the relationships between the architectural components. However, developing a detailed architectural description is an expensive and time-consuming process.
Information Systems
Allows for controlled access to a large base of information. All systems that involve interaction with a shared database can be considered to be transaction-based information systems. Almost always web-based systems, where the user interface is implemented in a web browser. -Transaction Processing System -Can model these systems using a layered architecture. -General ex: Top layer supports UI and bottom layer is the system database. The user communications layer handles all input and output from the UI, and the information retrieval layer includes application-specific logic for accessing and updating the database. Layers in this model can map directly onto servers in a distributed internet-based system. -Information and resource management systems are sometimes also transaction processing systems. -Organization of servers in these systems usually reflects the 4-layer generic architecture model (above). These systems are often implemented as distributed systems with a multi-tier client-server architecture. 1. Web server is responsible for all user communications, with the UI implemented using a web browser. 2. The application server is responsible for implementing application-specific logic as well as info storage and retrieval requests. 3. The database server moves info to and from the database and handles transaction management. -Multiple servers allows for high throughput and makes it possible to handle thousands of transactions per minute. As demand increases, servers can be added to each level to cope with the extra processing involved.
Systems in same application domain
Although each software system is unique, systems in the same application domain often have similar architectures that reflect the fundamental concepts of the domain. -ex: Application product lines are applications built around a core architecture with variants that satisfy specific customer requirements
Conceptual View
An abstract view of the system that can be the basis for decomposing high-level requirements into more detailed specifications, help engineers make decisions about components that can be reused, and represent a product line rather than a single system. -Hofmeister's additional view -Conceptual views of a system's architecture are almost always developed during the design process. They are used to explain the system architecture to stakeholders and to inform architectural design making.
Large-Scale Reuse
An architectural model is a compact, manageable description of how a system is organized and how the components interoperate. The system architecture is often the same for systems with similar requirements and so can support large-scale software reuse.
Output of the architectural design process
An architectural model that describes how the system is organized as a set of communicating components
What stage is architectural design in the software development process?
Architectural design is the first stage in the software design process. It is the critical link between design and requirements engineering, as it identifies the main structural components in a system and the relationships between them.
Architectural Views
Architectures may be documented from several different perspectives or views. It's impossible to represent all relevant info about a system's architecture in a single diagram, as a graphical model can only show one view or perspective of the system. It might show how a system is decomposed into modules, how the runtime processes interact, or the different ways in which system components are distributed across a network. Because all of these are useful at different times, for both design and documentation, you usually need to present multiple views of the software architecture. -You should develop the views that are useful for communication and not worry about whether or not your architectural documentation is complete.
Architecture in the Large
Concerned with the architecture of complex enterprise systems that include other systems, programs, and program components. These enterprise systems are distributed over different computers, which may be owned and managed by different companies.
Architecture in the Small
Concerned with the architecture of individual programs. At this level, we are concerned with the way that an individual program is decomposed into components.
Transaction Processing Systems (Overview)
Database-centered applications that process user requests for information and update the information in a database. Interactive systems that allow information in a database to be remotely accessed and modified by a number of users. -These are the most common types of interactive business systems. -ex: Interactive banking systems, e-commerce systems, information systems, and booking systems. (A lot of web-based business systems)
Architectural Design Evaluation
Evaluating an architectural design can be difficult because the true test of an architecture is how well the system meets its functional and non-functional requirements when it's in use. You can do some evaluation by comparing your design against reference architectures or generic architectural patterns.
As a means of assessing components for reuse
If you have components you might be able to reuse, you can compare these with the generic structures to see whether there are comparable components in the application architecture.
As a design checklist
If you have developed an architectural design for an application system, you can compare this with the generic application architecture. You can check that your design is consistent with the generic architecture.
As a vocabulary for talking about applications
If you're discussing a specific application or trying to compare applications, then you can use the concepts identified in the generic architecture to talk about these applications.
As a starting point for the architectural design process
If you're unfamiliar with the type of application that you're developing, you can base your initial design on a generic application architecture. You then specialize this for the specific system that is being developed.
System Analysis
Making the system architecture explicit at an early stage in the system development requires some analysis. Architectural design decisions have a profound effect on whether or not the system can meet critical requirements such as performance, reliability, and maintainability.
Architectural Description Languages (ADL)
More specialized languages used to describe system architectures (versus using the UML). -Basic elements of ADLs are components and connectors, and they include rules and guidelines for well-formed architectures. However, because ADLs are specialist languages, domain ad application specialists find it hard to understand and use ADLs
Server
Software components. Several servers may run on the same computer. -ex: print servers that offer printing services, file servers that offer file management services, compile server that offers programming language compilation services -Clients may have to know names of servers and the services they provide but servers don't need to know the identity of clients or how many clients are accessing their services. -Clients access the services provided by a server through remote procedure calls using a request-reply protocol (such as http), where a client makes a request to a server and waits until it receives a reply from that server.
Possible architecture for a LPS compiler
Source language instructions define the program to be executed, and translator converts these into instructions for an abstract machine. These instructions are then interpreted by another component that fetches the instructions for execution and executes them using (if necessary) data from the environment. The output of the process is the result of interpreting the instructions on the input data. -For many compilers, the interpreter is the system hardware that processes machine instructions, and the abstract machine is a real processor. However, for dynamically types languages (Ruby/ Python), the interpreter is a software component. -Can be implemented using a composite of a repository and a pipe and filter model. In a compiler architecture, the symbol table is a repository for shared data. The phases of lexical, syntactic, and semantic analysis are organized sequentially and communicate through the shared symbol table. This pipe and filter model of language compilation is effective in batch environments where programs are compiled and executed without user interactions; ex: translation of one XML doc to another. It's less effective when a compiler is integrated with other language processing tools such as a structured editing system, an interactive debugger, program formatter. In this situation, changes from one component need to be reflected immediately in other components. It's better to organize the system around a repository if you're implementing a general, language-oriented programming environment.
Language Processing Systems (Overview)
Systems in which user's intentions are expressed in a formal language. The LPS processes this language into an internal format and then interprets this internal representation. All software development relies on LPS. Used to translate texts from one language into another and to carry out the instructions specified in the input language. They include a translator and an abstract machine that executes the generated language. -ex: compilers which translate high-level language programs into machine code. However, LPS are also used to interpret command languages for databases and information systems, and markup languages such as XML.
As a way of organizing the work of the development team
The application architectures identify stable structural features of the system architectures, and in many cases, it's possible to develop these in parallel. You can assign work to group members to implement different components within the architecture.
Stakeholder Communication
The architecture is a high-level presentation of the system that may be used as a focus for discussion by a range of different stakeholders
Idea behind Architectural Patterns
The idea of patterns as a way of presenting, sharing, and reusing knowledge about software systems has been adopted in a number of areas of software engineering.
Conflict between architectures
There is potential conflict between some of these non-functional requirements and their architectures. If performance and maintainability are important system requirements, then some compromise must be found. This can sometimes be done by using different architectural patterns or styles for separate parts of the system.
Transaction Processing Systems (detail)
Transaction processing systems are designed to process user requests for information from a database, or requests to update a database. Technically, a database transaction is part of a sequence of operations and is treated as a single unit (an atomic unit). All of the operations in a transaction have to be completed before the database changes are made permanent. This ensures that failure of operations within a transaction does not lead to inconsistencies in the database. -Usually interactive systems in which users make asynchronous requests for service. -First, user makes a request to the system through an I/O processing component. The request is processed by some application-specific logic. A transaction is created and passed to a transaction manager, which is usually embedded in the database management system. After the transaction manager has ensured that the transaction is properly completed, it signals to the application that processing has finished. -TPS may be organized as a 'pipe-and-filter' architecture, with system components responsible for input, processing, and output.
Language processing Systems (detail)
Translate one language into an alternative representation of that language and, for programming languages, may also execute the resulting code. -ex: compilers, natural language processing systems (may translate one natural language to another).
What is architectural design concerned with?
Understanding how a software system should be organized and designing the overall structure of that system. -Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used, and the ways in which the architecture should be documented and evaluated.
Transaction
User Perspective: Any coherent sequence of operations that satisfies a goal. If the user transaction does not require the database to be changed, then it may not be necessary to package this as a technical database transaction. -ex: Customer request to withdraw money from a bank account using an ATM. Check account balance to see if sufficient funds are available, modifying the balance by the amount withdrawn, and sending commands to the ATM to deliver the cash. Until all these steps are complete, the transaction is incomplete and the customer accounts database is not changed. System is composed of two cooperating software components: the ATM software (implements input and output components) and then account processing software in the bank's database server (processing component.)
Choosing an Architectural Pattern (style)
You have to choose the most appropriate structure/ organization that will enable you to meet the system requirements. To decompose structural system units, you decide on a strategy for decomposing components into sub-components. Finally, in the control modeling process, you develop a general model of the control relationships between the various parts of the system and make decisions about how the execution of components is controlled. -Because of the close relationship between non-functional system characteristics and software architecture, the choice of architectural style and structure should depend on the non-functional requirements of the system.
Example of an information and resource management systems that is also a transaction processing systems
e-commerce systems are internet-based resource management systems that accept electronic orders for goods or services and then arrange delivery of these to the customer. In an e-commerce system, the application-specific layer includes additional functionality supporting a "shopping cart" in which users can place a number of items in separate transactions, then pay for them all together in a single transaction.
