1. Software Engineering Architectural Design Chapter 6 Dr.Doaa Samy
Modified from Sommerville’s originals

2. Objectives  Understand the importance of architectural design.2
 Understand the importance of architectural design.
 Introduce to the architectural views.
 Understand the decisions that be made during architectural design.
 Know the architectural patterns that are often used in different types of application system.

3. Architecture 3
 Architecture: Floor plan

4. Software Design The software design process is composed of four main4
The software design process is composed of four main
design activities:
 Architectural design  this chapter.
 Data design.
 Component design.
 Interface design.

5. Software Design Deliverables5
The main deliverables of the Software Design are:
 Software architecture.
 Data structures.
 Pseudo code.
 Interface designs.
 Software Design Document.

6. Software Architecture6
 Architectural Design: The design process concerned with understanding how a system should be organized and designing the overall structure of that system.
 Software Architecture model: Output of this design process, describes how the system is organized as a set of communicating components.
 A Software Architecture consists of:
 Elements (components) with certain properties/behaviors.
 Relationships between them.
 Description of permitted and forbidden interactions.

7. Architectural Design 7
 It is the first stage in the software design process.
 It links between specification and design process.
 Often carried out in parallel with some of the specification activities. However, this is not ideally.
 It involves identifying main structural components in a system and the relationships between them.

8. Advantages of Explicit Architecture8
 Three advantages of explicitly designing and documenting software architecture:
Stakeholder communication
 Architecture is a high-level presentation. So, it may be used as a focus of discussion by different stakeholders.
System analysis
 Means that analyzing of whether the system can meet its critical non- functional requirements.
Large-scale reuse
 System architecture is often the same for systems with similar requirements and so can support large-scale software reuse.

9. Architectural Representations9
UML was designed for describing object-oriented systems, it is not concerned with the design process. Object classes are too close to be useful for architectural description.
Simple, informal block diagrams showing components and relationships are the most frequently used method.
Boxes indicate to the components while arrows mean that data and or control signals are passed from component to another in the direction of the arrows.

10. Box and Line Diagrams 10
 Block diagrams are an appropriate way of describing the system architecture during the design process.
 Although they are very abstract, do not show the nature of relationships between components nor the components’ visible properties, they are useful for communication with stakeholders and for project planning.

11. Architectural Views 11
 It is impossible to represent all relevant information about a system’s architecture in a single architectural model.
 Each model only shows one view or perspective of the system such as: logical view, process view, development view, and physical view.
 For both design and documentation, you usually need to present multiple views of the software architecture.

12. You don’t have to reinvent the wheel!
Architectural Styles and Patterns 12
 The architectural model of a system may conform to a generic architectural pattern or style.
 Architectural Patterns/Styles capture the essence of an architecture that used in different software systems.
 An awareness of these styles can simplify the problem of defining system architecture.
 However, most large systems are heterogeneous and do not follow a single architectural style.
You don’t have to reinvent the wheel!

13. Architecture and System Characteristics13
A particular architectural style that you choose for a system should depend on the non-functional requirements (System Characteristics):
 Performance
 If it is critical, use large and few components  less communications.
 Security
 If it is critical, use a layered architecture with critical assets in the innermost layer with high level of validation in this layer.
 Safety
 If it is critical, put safety-critical features in one or small number of sub- systems to reduces costs in the event of failure.
 Availability
 If it is critical, include redundant components  update without stop.
 Maintainability
 If it is critical, use separate components and avoid shared data structure.

14. Fundamental Questions in Architectural Design14
 Is there a generic application architecture that can be used?
 How will the system be distributed across cores? processors?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed?
 What control strategy should be used?
 What architectural organization to deliver non-functional requirements?
 How will the architectural design be evaluated?
 How should the architecture be documented?

15. Architectural Design Decisions15
 Architectural design is a creative process where you design a system organization that will satisfy the functional and non-functional requirements.
 Activities within the process depend on the type of system being developed, experience of the system architect, and the specific requirements for the system.
 Therefore, it is useful to think of architectural design as a series of decisions rather than a sequence of activities.

16. Architectural Design Decisions Cont.16
 The software architect must make decisions about:
System organization (structure) style.
Decomposition style.
Control style (Not covered).
 Evaluating different architectures for a software is sometimes refereed to as Tradeoff analysis.

17. 1. System Organization system.17
 Reflects the basic strategy that is used to organize a
system.
 Three architectural styles are widely used:
 An abstract machine or layered style;
 A shared data repository style;
 A client/server style.

18. Layered Architecture  Used to model the interfacing of sub-systems.18
 Used to model the interfacing of sub-systems.
 Organizes the system into a set of layers (or abstract machines) each of which provide a set of services.
 Supports the incremental development of sub-systems in different layers. When a layer interface changes, only the adjacent layer is affected.
 Each layer provides a set of services to the layer above and serves as a client to the layer below.

19. Layered Architecture 19

20. The Architecture of the LIBSYS System20

21. Advantages & Disadvantages of Layered Style21
 Advantages:
 Supports incremental development.
 Changeable (if a layer changes, only adjacent layers are affected).
 Disadvantages:
 Structuring systems into layers is difficult.
 Inner layers may provides facilities required by all layers (e.g. file management).
 Performance is degraded.

22. Repository Style  Sub-systems must exchange data.22
 Sub-systems must exchange data.
 This may be done in two ways:
Shared data is held in a central database or repository and may be accessed by all sub-systems;
Each sub-system maintains its own database and passes data explicitly to other sub-systems.
 When?
 large amounts of data are to be shared, the repository model of sharing is most commonly used.

23. Advantages & Disadvantages of Repository Style23
 Advantages:
 Efficient way to share large amounts of data;
 Sub-systems need not be concerned with how data is produced;
 Centralized management e.g. backup, security, 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;
 No scope for specific management policies;
 Difficult to distribute efficiently.

24. Repository Style for Project24

25. Client-Server Architecture25
 Distributed system model which shows how data and processing is distributed across a range of components.
 Set of stand-alone servers which provide specific services such
as printing, data management, etc.
 Set of clients which call on these services.
 Network which allows clients to access servers.
 Client and server exchange data for processing.

26.  Advantages:  Disadvantages:
Advantages & Disadvantages of Client–Server 26
 Advantages:
 Servers can be distributed across a network.
 General functionality (e.g. printing service) can be available to all clients and does not need to be implemented by all services.
 Easy add new server or upgrade existing one.
 Disadvantages:
 Security problem, each server will be suspected if a fault happen.
 Performance may be unpredictable because it depends on the
network as well as the system.
 Management problems with servers owned by different organizations.

27. Client–Server Architecture for a Film Library27

28. 2. Decomposition Styles  Sub-systems are decomposed into modules.28
 Sub-systems are decomposed into modules.
 We will cover one modular decomposition models
 Pipe and filter or data-flow model where the system is decomposed into functional modules which transform inputs
to outputs.

29. Pipeline Model 29
Input Function
Output 31

30. Pipe and Filter Architecture30
 Functional transformations process their inputs to
produce outputs.
 The processing of the data in a system is organized so that each processing component (filter) is discrete and carries out one type of data transformation. The data flows (as in a pipe) from one component to another for processing.

31. Pipe and Filter 31

32. Invoice Processing System32

33.  Advantages:  Disadvantages: The Pipe and Filter Pattern33
 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.
 Disadvantages:
 Not really suitable for interactive systems.
 Although simple textual input and output can be modeled in this way, graphical user interfaces have more complex I/O formats which difficult to translated into a form compatible with the pipelining model.

34. The Architectures of Application34
 Application systems are intended to meet a business or organizational needs.
 All businesses have much in in common—they need to hire people, issue invoices, keep accounts, and so on.
 Commonalities led to development of software architectures that describe structure and organization of types of software systems.
 The application architecture may be re-implemented when developing new systems, but many systems application reuse is possible without reimplementation.

35. The Architectures of Application35
 There are many types of application system and, in some cases, they may seem to be very different.
Focus here is on two processing systems:
 Transaction processing systems:
 E-commerce systems.
 Reservation systems.
 Language processing systems:
 Compilers.
 Command interpreters.

36. Example 1: Transaction Processing Systems36
 Process user requests for information from a database or requests to update the database.
 From a user perspective a transaction is:
 Any sequence of operations that satisfies a goal;
 For example - find the times of flights from London to Paris.
 Users make asynchronous requests for service which are then processed by a transaction manager.
 All operations in a transaction have to be completed before the database changes are made permanent. This ensures that failure of operations within the transaction does not lead to inconsistencies in the database

37. Example 2: Language Processing Systems37
Language processing systems are systems in which the user’s intentions are expressed in a formal language. The best-known example for these systems are compilers
Compiler‘s components may implemented using different styles.

38. Summery 38
 A software architecture is a description of how a software system is organized.
 Architectural design decisions include decisions on the type of application, the distribution of the system, the architectural styles to be used.
 Architectural style are a means of reusing knowledge about generic system architectures. They describe the architecture, explain when it may be used and describe its advantages and disadvantages.

39. Summary 39
 Models of application systems architectures help us understand and compare applications, validate application system designs and assess large-scale components for reuse.
 Transaction processing systems are interactive systems allow information in a database to be remotely accessed and modified by number of users.
 Language processing systems are used to translate texts from one language into another and to carry out the instructions specified in the input language.