Unit-02#SENG 352.pdf

SENG 352 Software Design and Architecture Unit-2 Software Architectural Design Compiled and prepared by: Dr. Shahanawaj Ahamad Associate Professor, Department of Software Engineering College of Computer Science and Engineering, University of Hail...

SENG 352 Software Design and Architecture Unit-2 Software Architectural Design Compiled and prepared by: Dr. Shahanawaj Ahamad Associate Professor, Department of Software Engineering College of Computer Science and Engineering, University of Hail [email protected] 1 Contents 1. Design in General 2. Design in Software Architecture 2.1 Architectural Design 2.2 Element Interaction Design 2.3 Element Internals Design 3. Important of Architectural Design 4. Architectural Drivers 4.1 Design Purpose 4.2 Quality Attributes 4.3 Architectural Concerns and Constraints 2 5. Design Concepts: The Building Blocks for Creating Structures 5.1 Reference Architectures 5.2 Architectural Design Patterns 5.3 Deployment Patterns 6. Architecture Design Decisions 3  1. Design in General Design is both a verb and a noun. Design is a process, an activity, and hence a verb. The output of the design process is the thing that is visual. The noun, the artifact that you will eventually implement. Designing means making decisions to achieve goals and satisfy requirements and constraints. The outputs of the design process are a direct reflection of those goals, requirements, and constraints. Think about houses, for example. Why do traditional houses in China look different from those in Switzerland or Algeria? 4  2. Design in Software Architecture Architectural design for software systems involves making decisions, working with available skills and materials, to satisfy requirements and constraints. In architectural design, we make decisions to transform our design purpose, requirements, constraints, and architectural concerns—what we call the architectural drivers—into structures, as shown in Figure 2.1. These structures are then used to guide the project. They guide analysis and construction, and serve as the foundation for educating a new project member. They also guide cost and schedule estimation, team formation, risk analysis and mitigation, and implementation. 5 FIGURE 2.1 Overview of the architecture design activity (Architect image © Brett Lamb) 6  Architectural design is, therefore, a key step to achieving your product and project goals. Some of these goals are technical (e.g., achieving low and predictable latency in a video game or an e-commerce website), and some are nontechnical (e.g., keeping the workforce employed, entering a new market, meeting a deadline). The decisions that an architect, make will have implications for the achievement of these goals and may, in some cases, be in conflict, need attention in correct directions. 7  2.1 Architectural Design In the AD phase, the software requirements are transformed into definitions of software components and their interfaces, to establish the framework of the software. This is done by examining the SRD and building a 'physical model' using recognized software engineering methods. The physical model should describe the solution in concrete, implementation terms. The logical model produced in the SR phase structures the problem and makes it manageable, the physical model does the same for the solution. The physical model is used to produce a structured set of component specifications that are consistent, coherent and complete. Each specification defines the functions, inputs and outputs of the component. 8  The major software components are documented in the Architectural Design Document (ADD). The ADD gives the developer's solution to the problem stated in the SRD. The ADD must cover all the requirements stated in the SRD, but avoid the detailed consideration of software requirements that do not affect the structure. 9 The main outputs of the AD phase are the: Architectural Design Document (ADD) Software Project Management Plan for the DD phase (SPMP/DD) Software Configuration Management Plan for the DD phase(SCMP/DD) Software Verification and Validation Plan for the DD Phase (SVVP/DD) Software Quality Assurance Plan for the DD phase (SQAP/DD) Integration Test Plan (SVVP/IT) 10 Following figure 2.2 summarizes activities and document flow in the AD phase. Figure 2.2: AD phase activities 11  2.2 Element Interaction Design Interaction design is the design of the interaction between users and products. Most often when software professional talk about interaction design, the products tend to be software products like apps or websites. The goal of interaction design is to create products that enable the user to achieve their objective(s) in the best way possible according to requirement documents. 12  There’s a huge overlap between interaction design and UX design. UX design is about shaping the experience of using a product. The most part of that experience involves some interaction between the user and the product. UX design is more than interaction design: It also involves user research (finding out who the users are in the first place) Creating user personas (why, and under what conditions, would they use the product) Performing user testing and usability testing, etc. 13 The 5 dimensions of interaction design The 5 dimensions of interaction design is a useful model to understand what interaction design involves. Gillian Crampton Smith, an interaction design academic, first introduced the concept of four dimensions of an interaction design language. Kevin Silver, senior interaction designer at IDEXX Laboratories, added the fifth dimension. 14 1D: Words Words—especially those used in interactions. Like button labels should be meaningful and simple to understand. Words should communicate information to users, but not too much information to overwhelm the user. 2D: Visual representations This concerns graphical elements Like images, typography and icons that users interact with. These usually supplement the words used to communicate information to users. 15 3D: Physical objects or space Through what physical objects do users interact with the product? A laptop, with a mouse or touchpad? Smartphone, with the user’s fingers? Within what kind of physical space does the user do so? The user standing in a crowded train while using the app on a smartphone, or sitting on a desk in the office surfing the website? These all affect the interaction between the user and the product. 16 4D: Time It is the amount of time a user spends interacting with the product Can users track their progress, or resume their interaction some time later? While this dimension sounds a little abstract, it mostly refers to media that changes with time (animation, videos, sounds). Motion and sounds play a crucial role in giving visual and audio feedback to users’ interactions. 17 5D: Behavior This includes the mechanism of a product: how do users perform actions on the website? How do users operate the product? In other words, it’s how the previous dimensions define the interactions of a product. It also includes the reactions—for instance emotional responses or feedback—of users and the product. 18 Interaction Design Methods: Defining Use Cases, a use case is a written description of how users will perform tasks on an application or product. Use case outlines the topics from a user’s point of view. Card Sorting, card sorting is a method used to help design or evaluate the information architecture of a product. In a card sorting session, participants organize topics written in cards into categories. Prototyping, prototype is a draft version of a proposed solution against a specific problem. It is used for validating ideas before implementation and iterative improvements. 19  2.3 Element Internals Design A third level of design follows element interaction design, which we call element internals design. In this level of design, which is usually conducted as part of the element development activities, the internals of the elements identified in the previous design level are established, so as to satisfy the element’s interface. 20  During architectural design, the architect may need to delve as deeply as element internals design to achieve a particular architectural driver. Architectural design can involve considerable detail, in terms of “high- level design” or “detailed design”. 21 Detailed Design? The term “detailed design” is often used to refer to the design of the internals of modules. Although it is widely used, we really don’t like this term, which is presented as somehow in opposition to “high-level design”. We prefer the more precise terms “architectural design”, “element interaction design”, and “element internals design”. 22  “high-level design” should be somehow “higher” or more abstract, and cover more of the architectural landscape than “low-level design” So here is what we recommend: Just avoid using terms such as “high”, “low”, or “detailed” altogether. There is always a better, more precise choice, such as “architectural”, “element interaction”, or “element internals” design! 23  3. Why Is Architectural Design So Important? There is a very high cost to a project of not making certain design decisions, or of not making them early enough. An initial architecture is critical for project proposals (or, as it is sometimes called in the consulting world, the pre-sales process). Without doing some architectural thinking and some early design work, you cannot confidently predict project cost, schedule, and quality. Even at this early stage, an architecture will determine the: Key approaches for achieving architectural drivers The gross work-breakdown structure The choices of tools and skills Technologies needed to realize the system. 24  4. Architectural Drivers Before commencing design with any other design method, you need to think about what you are doing and why. We categorize these “what” and “why” questions as architectural drivers. As shown in Figure 2.1, these drivers include Design purpose Quality attributes Primary functionality Architectural concerns Constraints These are critical to the success of system and they drive and shape the architecture. 25  4.1 Design Purpose Design purposes may include: You may be doing architecture design as part of a project proposal. As part of determining project feasibility, schedule, and budget. Break down the architecture in sufficient detail that the units of work. Process of creating an exploratory prototype. To explore the domain To explore new technology To place something executable in front of a customer To elicit rapid feedback To explore more quality attributes. 26  4.2 Quality Attributes Quality attributes are defined as being measurable or testable properties of a system. Among the drivers, quality attributes are the ones that shape the architecture the most significantly. The best way to discuss, document, and prioritize quality attribute requirements is as a set of scenarios. A scenario, in its most basic form, describes the system’s response to some stimulus. 27 FIGURE 2.3 The six parts of a quality attribute scenario 28 FIGURE 2.4 ISO/IEC FCD 25010: Product Quality Attributes Standard 29  4.3 Primary Functionality Functionality is the ability of the system to do the work for which it was intended. As opposed to quality attributes, the way the system is structured does not normally influence functionality. You can have all of the functionality of a given system coded in a single enormous module; it is a bad practice. You can have it neatly distributed across many smaller, highly cohesive modules. 30 There are two important reasons why you need to consider primary functionality when designing an architecture: 1. You need to think how functionality will be allocated to elements (usually modules) to promote modifiability or reusability, and work assignments planning. 2. Some quality attribute scenarios are directly connected to the primary functionality in the system. For example, in a movie streaming application: Primary use cases is to watch a movie, is associated with a performance quality attribute scenario. Such as “Once the user presses play, the movie should begin streaming in no more than 5 seconds”. 31  4.4 Architectural Concerns Architectural concerns encompass additional aspects that need to be considered as part of architectural design but that are not expressed as traditional requirements. There are several different types of concerns: 1. General concerns. These are “broad” issues that deals with in creating: An overall system structure Allocation of functionality to modules Allocation of modules to teams Organization of the code base, startup and shutdown Supporting delivery, deployment, and updates. 32 2. Specific concerns. These are more detailed system-internal issues such as: Exception management Dependency management Configuration Logging Authentication Authorization 33  4.5 Constraints These constraints may take the form of: Mandated technologies Other systems with which your system needs to interoperate or integrate Laws and standards that must be complied with Abilities and availability of your developers Deadlines that are non-negotiable Backward compatibility with older versions of systems. A constraint is a decision over which you have little or no control as an architect. Your job as an architect is to satisfice: To design the best system that you can, despite the constraints you face. 34 5. Design Concepts The Building Blocks for Creating Structures Design is not random, but rather is planned, intentional, rational, and directed. The software architecture community is a body generally accepted design principles that can guide us to create high-quality designs with predictable outcomes. For example, some well-documented design principles are oriented toward the achievement of specific quality attributes: 35  To help achieve high modifiability, aim for good modularity, means high cohesion and low coupling. To help achieve high availability, avoid having any single point of failure. To help achieve scalability, avoid having any hard-coded limits for critical resources. To help achieve security, limit the points of access to critical resources. To help achieve testability, externalize state. In addition, we have evolved reusable realizations of these abstract approaches in design and in code. We call these reusable realizations design concepts, and they are the building blocks from which the structures that make up the architecture are created. 36  4 + 1 view model of software architecture A logical view, which shows the key abstractions in the system as objects or object classes. A process view, which shows how, at run-time, the system is composed of interacting processes. A development view, which shows how the software is decomposed for development. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. Related using use cases or scenarios (+1) 37  5.1 Reference Architectures Reference architectures are blueprints that provide an overall logical structure for particular types of applications. A reference architecture is a reference model mapped onto one or more architectural patterns. It is proven in business and technical contexts. An example of a reference architecture for the development of web applications is shown in Figure 2.5. 38  This reference architecture establishes the main layers for this type of application Presentation Business Data As well as the types of elements that occur within the layers and the responsibilities of these elements, such as UI components Business components Data access components Service agents Also, this reference architecture introduces cross-cutting concerns, such as security and communication etc. 39 FIGURE 2.5 Example reference architecture for the development of web applications from the Microsoft Application Architecture Guide (Key: UML) 40  Reference architectures may be confused with architectural styles, but these two concepts are different. Architectural styles (such as “Pipe and Filter” and “Client Server”) define types of components and connectors in a specified topology that are useful for structuring an application either logically or physically. Such styles are technology and domain agnostic. Reference architectures, in contrast, provide a structure for applications in specific domains, and they may embody different styles. While architectural styles tend to be popular in academia, reference architectures seem to be preferred by practitioners—which is also why we favor them in our list of design concepts. 41  5.2 Architectural Design Patterns Design patterns are conceptual solutions to recurring design problems that exist in a defined context. Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments. Patterns should include information about when they are and when the are not useful. Patterns may be represented using tabular and graphical descriptions. 42  The Model-View-Controller (MVC) pattern Name MVC (Model-View-Controller) Description Separates presentation and interaction from 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 defines and manages how the data is presented to the user. The Controller component manages user interaction (e.g., key presses, mouse clicks, etc.) and passes these interactions to the View and the Model. Example Figure 2.6 shows the architecture of a web-based application system organized using the MVC pattern. 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 made in one representation shown in all of them. Disadvantages Can involve additional code and code complexity when the data model and interactions 43 are simple. The organization of the Model-View-Controller FIGURE 2.6 44 Web application architecture using the MVC pattern FIGURE 2.7 45  Layered architecture Used to model the interfacing of sub-systems. Organises 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. However, often artificial to structure systems in this way. 46  The Layered architecture pattern Name Layered architecture 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. Example A layered model of a system for sharing copyright documents held in different libraries, as shown in Figure 2.8. When used Used when building new facilities on top of existing systems; when the development is spread across several teams with each team responsibility for a layer of functionality; when there is a requirement for multi-level security. Advantages Allows replacement of entire layers so long as the interface is maintained. Redundant facilities (e.g., 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. 47 A generic layered architecture FIGURE 2.8 48 The architecture of the LIBSYS system FIGURE 2.9 49 Layered information system architecture FIGURE 2.10 50 The architecture of the MHC-PMS FIGURE 2.11 51 Generic Architecture Models Repository Client Server Pipe and Filter 52  Repository architecture 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 a this is an efficient data sharing mechanism. 53  The Repository Architecture pattern Name Repository 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. Example Figure 2.12 is an example of an IDE where the components use a repository of system design information. Each software tool generates information which is then available for use by other tools. 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 of the existence of other components. Changes made by one component can be propagated to all components. All data can be managed consistently (e.g., 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. 54 A repository architecture for an IDE FIGURE 2.12 55  Client-server architecture Distributed system model which shows how data and processing is distributed across a range of components. ▪ Can be implemented on a single computer. 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. 56  The Client–server pattern Name Client-server Description In a client–server architecture, the functionality of the system is organized into services, with each service delivered from a separate server. Clients are users of these services and access servers to make use of them. Example Figure 2.13 is an example of a film and video/DVD library organized as a client–server system. 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 The principal advantage of this model is that servers can be distributed across a network. General functionality (e.g., a printing service) 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 so susceptible to denial of service attacks or server failure. Performance may be unpredictable because it depends on the network as well as the system. May be management problems if servers are owned by different organizations. 57  A client–server architecture for a film library FIGURE 2.13 58  Pipe and filter architecture Functional transformations process their inputs to produce outputs. May be referred to as a pipe and filter model (as in UNIX shell). Variants of this approach are very common. When transformations are sequential, this is a batch sequential model which is extensively used in data processing systems. Not really suitable for interactive systems. 59  The pipe and filter pattern Name Pipe and filter Description 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. Example Figure 2.14 is an example of a pipe and filter 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. Disadvantages The format for data transfer has to be agreed upon 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 functional transformations that use incompatible data structures. 60 An example of the pipe and filter architecture FIGURE 2.14 61  Application architectures A generic application architecture is an architecture for a type of software system that may be configured and adapted to create a system that meets specific requirements. As a starting point for architectural design. As a design checklist. As a way of organizing the work of the development team. As a means of assessing components for reuse. As a vocabulary for talking about application types. 62  Examples of application types Data processing applications ▪ Data driven applications that process data in batches without explicit user intervention during the processing. Transaction processing applications ▪ Data-centered applications that process user requests and update information in a system database. Event processing systems ▪ Applications where system actions depend on interpreting events from the system’s environment. Language processing systems ▪ Applications where the users’ intentions are specified in a formal language that is processed and interpreted by the system. 63 FIGURE 2.15 64  5.3 Deployment Patterns Another type of pattern that we prefer to consider separately is deployment patterns. These patterns provide models on how to physically structure the system to deploy it. Some deployment patterns, such as the one shown in following Figure 2.16 are useful to establish an initial physical structure of the system in terms of tiers (physical nodes). More specialized deployment patterns, such as the Load- Balanced Cluster in Figure 2.17, are used to satisfy quality attributes such as availability, performance, and security. 65 FIGURE 2.16 Four-tier deployment pattern from the Microsoft Application Architecture Guide (Key: UML) 66 FIGURE 2.17 Load-Balanced Cluster deployment pattern for performance from the Microsoft Application Architecture Guide (Key: UML) 67  6. Architecture Design Decisions Experienced architects, when faced with a design challenge, typically entertain a set of “candidate” decisions; from this set, they choose a best candidate and instantiate that. They might select this “best” candidate based on experience, constraints, or some form of analysis such as prototyping or simulation. Each candidate pattern must be chosen and its instantiation must be analyzed. For example, if you chose the Layers pattern, you would still have many decisions to make: how many layers there will be, how strict the layering will be, which specific services will be placed into each layer, what the interfaces between these functions will be, and so forth. 68  Architectural design decisions – common questions (though a creative process) Is there a generic application architecture that can be used? How will the system be distributed? What architectural styles are appropriate? What approach will be used to structure the system? How will the system be decomposed into modules? What control strategy should be used? How will the architectural design be evaluated? How should the architecture be documented? 69 Thank you 70