Download presentation
Presentation is loading. Please wait.
Published byDeborah Caren Allison Modified over 9 years ago
1
Architectural Design 1
2
Topics covered The role of Software Architecture. Architectural views Component and Connector view Architectural Styles 2
3
Architecture Architecture of a system provides a very high level view of the parts of the system and how they are related,to form the whole system. There is no unique structure of the system that can be described by its architecture; there are many possible structures. 3
4
Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture. 4
5
Architectural Diagram of a mobile phone
6
Architectural design An early stage of the system design process, represents the link between specification and design processes. Often carried out in parallel with some specification activities. It involves identifying major system components and their communications. Architecture facilitates development of a high-quality system. It also allows analysis of many of the system properties like performance that depend mostly on architecture to be done early in the software life cycle. 6
7
The architecture of a packing robot control system 7
8
Advantages of explicit architecture Stakeholder communication and understanding Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non- functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems Product-line architectures may be developed. 8
9
Architecture views There is no unique architecture of a system. For a building, if we want to see the floor plan, will shown one set of drawings. If an electrical engineer want to see how the electricity distribution has been planned, will be shown another set of drawings. if we are interested in safety and firefighting, another set of drawings is used. multiple drawings showing di ff erent views of a building, one view that predominates in construction—that of physical structure. These drawings are not independent of each other—they are all about the same building. 9
10
Architecture views In software, the different drawings are called views. There are three main architectural views of a system— module, component and connector, and allocation. In a module view, the system is viewed as a structure of programming modules like packages, classes, functions, etc. In a component and connector (C&C) view, the system is a collection of runtime entities called components, which interact with each other through the connectors. An allocation view describes how the different software units are allocated to hardware resources in the system. 10
11
Module View In a module view, the system is viewed as a collection of code units, each implementing some part of the system functionality. That is, the main elements in this view are modules. Examples of modules are packages, a class, a procedure, a method, a collection of functions, and a collection of classes. The relationships between these modules are also code-based and depend on how code of a module interacts with another module. Examples of relationships in this view are “is a part of”, “uses or depends on” and “generalization or specialization”. 11
12
component and connector (C&C) system is viewed as a collection of runtime entities called components. a component is a unit which has an identity in the executing system. Example--Objects (not classes), a collection of objects. While executing, components need to interact with others to support the system services. Connectors provide means for this interaction. Examples -- pipes and sockets. Shared data can also act as a connector. If the components use some middleware to communicate and coordinate, then the middleware is a connector. 12
13
Allocation An allocation view focuses on how the different software units are allocated to resources like the hardware, file systems, and people. They expose structural properties like which processes run on which processor, and how the system files are organized on a file system. 13
14
Architecture views--summary Module views show how the software is structured as a set of implementation units, C&C views show how the software is structured as interacting runtime elements, and allocation views show how software relates to non software structures. 14
15
Component and Connector View C&C view is most common, and is often the centerpiece of the architecture description. The C&C architecture view of a system has two main elements—components and connectors. Components are usually computational elements or data stores that have some presence during the system execution. Connectors define the means of interaction between these components. C & C view defines the components, and which component is connected to which connector and through what connector. 15
16
Component and Connector View A C&C view describes a runtime structure of the system— what components exist when the system is executing and how they interact during the execution. The C&C structure is essentially a graph, with components as nodes and connectors as edges. This view is often described by block diagrams specifying the different components and the different connectors between the components.ie, box and line drawings. 16
17
Components Components are generally units of computation or data stores in the system. A component is of a component type, where the type represents a generic component Examples of these types are clients, servers, filters, etc. Di ff erent domains may have other generic types like controllers, actuators, and sensors (for a control system domain). In a box-and-line diagram, often all components are represented as rectangular boxes.
18
Component Examples 18
19
Connectors The di ff erent components of a system are likely to interact while the system is in operation to provide the services expected of the system. For example, a component may interact with another using the procedure call mechanism (a connector), which is provided by the runtime environment for the programming language. However, the interaction may involve more complex mechanisms as well. Examples of such mechanisms are remote procedure call, TCP/IP ports, and a protocol like HTTP.
20
Connectors Connectors need not be binary, They may provide an n-way communication For example, a broadcast bus may be used as a connector, which allows a component to broadcast its message to all the other components. Some of the commonly used symbols.
21
Connector example Chapter 6 Architectural design21
22
Example: Architecture of the survey system Design and build a simple system,for taking an on-line survey of students on a campus. There is a set of multiple-choice questions, and the proposed system will provide the survey form to the student, who can fill and submit it on-line. when the user submits the form, he/she is also shown the current result of the survey. The system is best built using the web. A traditional 3- tier architecture is proposed. 22
23
Architecture of the survey system It consists of a client which will display the form that the student can complete and submit, and will also display the results. The second component is the server, which processes the data submitted by the student, and saves it on the database, which is the third component. The server also queries the database to get the outcome of the survey and sends the results in proper format (HTML) back to the client, which then displays the result. The C&C view is as shown in figure 23
24
Architecture of the survey system 24
25
Note Note that at the architecture level, a host of details are not discussed. How is the URL of the survey set? What are the modules that go into building these components and what language are they written in? The above architecture has no security(non student can take the survey). The proposed architecture now has a separate login form for the user, and a separate server component which does the validation. The architecture for this system is shown in Figure. 25
26
Architecture for the survey system with authentication 26
27
Architecture for the survey system with cache suppose we want the system to be extended in a di ff erent way. It was found that the database server is somewhat unreliable, and is frequently down. To make the system more reliable, and provide some facility for completing the survey even when the database is down. If the database is down or unavailable, the survey data is stored locally in a cache component, and the result saved in the cache component is used to provide the result to the student. 27
28
Architecture for the survey system with cache 28
29
Architecture styles for C & C views Different systems will have different architecture. There are some general architectures to represent general structures that are useful for architecture of a class of problems. These are called architectural styles. There are some common styles for a C&C view,These include pipe and filter, shared-data style, client-server style, publish-subscribe style, peer-to-peer style(object oriented style) and communicating processes styles. Each of these styles describes the types of components and connectors that exist and the constraints on how they are used. 29
30
Pipe and Filter Pipe-and-filter style of architecture is well suited for systems that primarily do data transformation whereby some input data is received and the goal of the system is to produce some output data by suitably transforming the input data. The pipe and filter has one type of component (filter) and one type of connector (pipe) and components can be connected through the pipe Example: To count the frequency of di ff erent words in a file. An architecture using the pipes-and-filter style for a system to achieve this is given in Figure 30
31
Pipe-and-filter example 31
32
Pipe-and-filter example This architecture proposes that the input data be first split into a sequence of words by a component Sequencer. This sequence of words is then sorted by the component Sorting, which passes the output of sorted words to another filter (Counting) that counts the number of occurrences of the di ff erent words. This structure of sorting the words first has been chosen as it will make the task of determining the frequency more e ffi cient, even though it involves a sort operation. 32
33
Applications This style is well suited for data processing and transformation. It is useful in text processing applications. Signal processing applications such applications typically perform encoding, error correction and other transformations on the data. 33
34
Shared data style In this style, there are two types of components—data repositories and data accessors. Data accessors read/write the repository and share information among themselves through the repository. Data repositories are where the system stores shared data—these could be file systems or databases. These components provide a reliable and permanent storage, take care of any synchronization needs for concurrent access, and provide data access support. 34
35
Shared data style Components of data accessors type, access data from the repositories, perform computation on the data obtained, and if they want to share the results with other components, put the results back in the depository. The data repository components are the means of communication and data transfer between them. Many database application use this architectural style, 35
36
Example, a student registration system in a university The system has a central repository which contains information about courses, students, prerequisites, etc. It has an Administrator component that sets up the repository, rights to di ff erent people, etc. The Registration component allows students to register and update the information for students and courses. The Approvals component is for granting approvals for those courses that require instructor’s consent. The Reports component produces the report regarding the students registered in di ff erent courses at the end of the registration. The Course Feedback is used for taking feedback from students at the end of the course. 36
37
Shared data example 37
38
Client-server style Another very common style used to build systems today is the client-server style. Client-server computing is one of the basic paradigms of distributed computing In this style, there are two component types—clients and servers. A constraint of this style is that a client can only communicate with the server, and cannot communicate with other clients. The communication between a client component and a server component is initiated by the client when the client sends a request for some service that the server supports. 38
39
Client-server style The server receives the request at its defined port, performs the service, and then returns the results of the computation to the client who requested the service. There is one connector type in this style—the request/reply type. A connector connects a client to a server. This type of connector is asymmetric. The communication is frequently synchronous. A general form of this style is an n-tier structure. In this style, a client sends a request to a server, but the server, in order to service the request, sends some request to another server. That is, the server also acts as a client for the next tier. This hierarchy can continue for some levels, providing an n-tier system. 39
40
Client-server style Example- 3-tier architecture Many of the client-server systems today use TCP ports for their connectors. The Web uses the HTTP for supporting this connector. 40
41
Film and picture library
42
Some other styles Publish-Subscribe Style In this style, there are two types of components. One type of component subscribes to a set of defined events. Other types of components generate or publish events. This type of style is most natural in user interface frameworks, where many events are defined (like mouse click) and components are assigned to these events. When that event occurs, the associated component is executed.
43
Peer-to-peer style, or object-oriented style If we take a client-server style, and generalize each component to be a client as well as a server, then we have this style. In this style, components are peers and any component can request a service from any other component. The object-oriented computation model represents this style. If we view components as objects, and connectors as method invocations, then we have this style. This model is the one that is primarily supported through middleware connectors like CORBA or.NET.
44
Communicating processes style The oldest model of distributed computing is that of communicating processes. Communicating processes style tries to capture distributed computing. The components in this model are processes or threads, which communicate with each other either with message passing or through shared memory.
45
Documenting Architecture Design The architecture forms the foundation for the system and rest of the design and development activities, and needs to be properly documented. A proper architecture document should describe the context in which the architecture was designed, the different architectural views that were created, and how the different views relate to each other. The architecture description should specify the different types of elements and their external behavior, and the architecture rationale. 45
46
Evaluating Architectures Architecture should be evaluated to see that it satisfies the requirements. A common approach is to do a subjective evaluation with respect to the desired properties. 46
47
The software architecture of an ATM system 47
48
The architecture of the MHC-PMS 48
49
The architecture of a language processing system 49
50
A pipe and filter compiler architecture 50
51
A repository architecture for a language processing system 51
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.