Unit-01#SENG 352(1).pdf

SENG 352 Software Design and Architecture Unit-1 Introduction to Software Architecture 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-1 Introduction to Software Architecture 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 Software Architecture Definitions Definitions Module Component Structure Physiological Structure Structures and Views The Importance of Software Architecture Life-Cycle Activities The Role of the Architect 2 Software Architecture The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Software architecture refers to the high-level structures of a software system and the discipline of creating such structures. It involves the set of significant decisions about the organization of a software system including the selection of structural elements and their interfaces by which the system is composed and behavior as specified in collaborations among those elements. 3 Simple Example 4  If ‘architecture’ is as a noun – “the structure of a software system”. If considered as a verb – “the process of defining these structures”. Architecture is the fundamental organization of a software system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. 5 Definition Software architecture is the high-level design and organization of software in which we make important decisions regarding its overall structure, such as the relationships between components, data flow patterns, and the mechanism for communication between different parts of the system. 6 Definition This definition stands in contrast to other definitions that talk about the system’s “early” or “major” design decisions. Many architectural decisions are made early, but not all are. Many decisions are made early that are not architectural. It’s hard to look at a decision and tell whether or not it’s “major.” Structures, on the other hand, are fairly easy to identify in software, and they form a powerful tool for system design. 7 To create a reliable, secure and efficient product, the attention is needed to architectural design which includes: Its overall organization How the software is decomposed into components The server organization The technologies that is used to build the software The architecture of a software product affects its performance, usability, security, reliability and maintainability 8 Architecture Is a Set of Software Structures A structure is a set of elements held together by a relation. Software systems are composed of many structures, and no single structure holds claim to being the architecture. There are three important categories of architectural structures. 1. Module 2. Component and Connector 3. Allocation 9 Module Structures Some structures partition systems into implementation units, which we call modules. Modules are assigned specific computational responsibilities, and are the basis of work assignments for programming teams. In large projects, these elements (modules) are subdivided for assignment to sub-teams. 10 Component-and-connector Structures Other structures focus on the way the elements interact with each other at runtime to carry out the system’s functions. We call runtime structures component-and-connector (C&C) structures. In our use, a component is always a runtime entity. Suppose the system is to be built as a set of services. The services, the infrastructure they interact with, and the synchronization and interaction relations among them form another kind of structure often used to describe a system. These services are made up of (compiled from) the programs in the various implementation units – modules. 11 Allocation Structures Allocation structures describe the mapping from software structures to the system’s environments organizational developmental installation execution For example Modules are assigned to teams to develop, and assigned to places in a file structure for implementation, integration, and testing. Components are deployed onto hardware to execute. 12 Which Structures are Architectural? A structure is architectural if it supports reasoning about the system and the system’s properties. The reasoning should be about an attribute of the system that is important to some stakeholder. These include functionality achieved by the system the availability of the system in the face of faults the difficulty of making specific changes to the system the responsiveness of the system to user requests, many others. 13 Architecture is an Abstraction An architecture comprises software elements and how the elements relate to each other. The architectural abstraction lets us look at the system in terms of its elements, how they are arranged, how they interact, how they are composed, what their properties are that support our system reasoning, and so forth. This abstraction is essential to taming the complexity of an architecture. We simply cannot, and do not want to, deal with all of the complexity all of the time. 14 Architecture Includes Behavior The behavior of each element is part of the architecture insofar as that behavior can be used to reason about the system. This behavior embodies how elements interact with each other, which is clearly part of the definition of architecture. Box-and-line drawings that are passed off as architectures are not architectures at all. When looking at the names of the boxes and lines a reader may well imagine their functionality and behavior. But it relies on information that is not present – and could be wrong! This does not mean that the exact behavior and performance of every element must be documented in all circumstances. Some aspects of behavior are fine-grained and below the architect’s level of concern. To the extent that an element’s behavior influences another element or influences the acceptability of the system as a whole, this behavior must be considered, and should be documented, as part of the software architecture. 15 Physiological Structures The neurologist, the orthopedist, the hematologist, and the dermatologist all have different views of the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on specific subsystems. The kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement’s behavior. Although these views are pictured differently and have different properties, all are inherently related, interconnected. Together they describe the architecture of the human body. So it is with software! 16 Physiological Structures 17 Structures and Views A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. A view consists of a representation of a set of elements and the relations among them. A structure is the set of elements itself, as they exist in software or hardware. In short, a view is a representation of a structure. For example, a module structure is the set of the system’s modules and their organization. A module view is the representation of that structure, documented according to a template in a chosen notation, and used by some system stakeholders. Architects design structures. They document views of those structures. 18 Module Structures Module structures embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed or procured. In any module structure, the elements are modules of some kind (perhaps classes, or layers, or merely divisions of functionality, all of which are units of implementation). Modules are assigned areas of functional responsibility; there is less emphasis in these structures on how the software manifests at runtime. Module structures allow us to answer questions such as these: What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use and depend on? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships? 19  The Importance of Software Architecture Software architecture is important for a wide variety of reasons, and a similarly wide variety of consequences stem from those reasons: Thirteen Reasons: 1. An architecture will inhibit or enable a system’s driving quality attributes. 2. The decisions made in an architecture allow you to reason about and manage change as the system evolves. 3. The analysis of an architecture enables early prediction of a system’s qualities. 4. A documented architecture enhances communication among stakeholders. 5. The architecture is a carrier of the earliest and hence most fundamental, hardest- to-change design decisions. 20 6. An architecture defines a set of constraints on subsequent implementation. 7. The architecture dictates the structure of an organization, or vice versa. 8. An architecture can provide the basis for evolutionary prototyping. 9. An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule. 10. An architecture can be created as a transferable, reusable model that form the heart of a product line. 11. Architecture-based development focuses attention on the assembly of components, rather than simply on their creation. 12. By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity. 13. An architecture can be the foundation for training a new team member. 21  Inhibiting or Enabling a System’s Quality Attributes Whether a system will be able to exhibit its desired (or required) quality attributes is substantially determined by its architecture. This is the most important message of this course! Performance: You must manage the time-based behavior of elements, their use of shared resources, and the frequency and volume of inter-element communication. Modifiability: Assign responsibilities to elements so that the majority of changes to the system will affect a small number of those elements. Security: Manage and protect inter-element communication and control which elements are allowed to access which information; you may also need to introduce specialized elements (such as an authorization mechanism). Scalability: Localize the use of resources to facilitate introduction of higher-capacity replacements, and you must avoid hardcoding in resource assumptions or limits. Incremental subset delivery: Manage inter-component usage. Reusability: Restrict inter-element coupling, so that when you extract an element, it does not come out with too many attachments to its current environment. 22  Reasoning About and Managing Change About 80 percent of a typical software system’s total cost occurs after initial deployment accommodate new features adapt to new environments, fix bugs, and so forth. Every architecture partitions possible changes into three categories A local change can be accomplished by modifying a single element. A nonlocal change requires multiple element modifications but leaves the underlying architectural approach intact. An architectural change affects the fundamental ways in which the elements interact with each other and will probably require changes all over the system. Obviously, local changes are the most desirable A good architecture is one in which the most common changes are local, and hence easy to make. 23  Early Prediction of System Qualities If we know that certain kinds of architectural decisions lead to certain quality attributes in a system, we can make those decisions and rightly expect to be rewarded with the associated quality attributes. When we examine an architecture we can look to see if those decisions have been made, and confidently predict that the architecture will exhibit the associated qualities. The earlier you can find a problem in your design, the cheaper, easier, and less disruptive it will be to fix. 24  Enhancing Communication Among Stakeholders Software architecture represents a common abstraction of a system that most, if not all, of the system’s stakeholders can use as a basis for creating mutual understanding, negotiating, forming consensus, and communicating with each other. The architecture—or at least parts of it—is sufficiently abstract that most nontechnical people can understand it adequately. Each stakeholder of a software system—customer, user, project manager, coder, tester, and so on—is concerned with different characteristics of the system that are affected by its architecture. For example: The user is concerned that the system is fast, reliable, and available when needed. The customer is concerned that the architecture can be implemented on schedule and according to budget. The manager is worried (in addition to concerns about cost and schedule) that the architecture will allow teams to work largely independently, interacting in disciplined and controlled ways. The architect is worried about strategies to achieve all of those goals. Architecture provides a common language in which different concerns can be expressed, negotiated, and resolved at a level that is intellectually manageable even for large, complex systems. 25  Earliest Design Decisions Software architecture is a manifestation of the earliest design decisions about a system. These early bindings carry enormous weight with respect to the system’s remaining development, its deployment, and its maintenance life. Each decision constrains the many decisions that follow. What are these early design decisions embodied by software architecture? Will the system run on one processor or be distributed across multiple processors? Will the software be layered? If so, how many layers will there be? What will each one do? Will components communicate synchronously or asynchronously? Will they interact by transferring control or data or both? Will the system depend on specific features of the operating system or hardware? Will the information that flows through the system be encrypted or not? What communication protocol will we choose? Imagine the nightmare of having to change any of these decisions. 26  Defining Constraints on an Implementation An implementation exhibits an architecture if it conforms to the design decisions prescribed by the architecture. The implementation must be implemented as the set of prescribed elements These elements must interact with each other in the prescribed fashion Each element must fulfill its responsibility to the other elements as dictated by the architecture. Each of these prescriptions is a constraint on the implementer. Element builders may not be aware of the architectural tradeoffs—the architecture (or architect) simply constrains them in such a way as to meet the tradeoffs. Example: an architect assigns performance budget to the pieces of software involved in some larger piece of functionality. If each software unit stays within its budget, the overall transaction will meet its performance requirement. Implementers of each of the constituent pieces may not know the overall budget, only their own. 27  Influencing the Organizational Structure Architecture prescribes the structure of the system being developed. That structure becomes engraved in the structure of the development project (and sometimes the structure of the entire organization). The architecture is typically used as the basis for the work-breakdown structure. The work-breakdown structure in turn dictates units of planning, scheduling, and budget inter-team communication channels configuration control and file-system organization integration and test plans and procedures; much more The maintenance activity will also reflect the software structure, with teams formed to maintain specific structural elements from the architecture. If these responsibilities have been formalized in a contractual relationship, changing responsibilities could become expensive or even litigious. 28  Enabling Evolutionary Prototyping Once an architecture has been defined, it can be analyzed and prototyped as a skeletal system. A skeletal system is one in which at least some of the infrastructure— how the elements initialize, communicate, share data, access resources, report errors, log activity, and so forth—is built before much of the system’s functionality has been created. This approach aids the development process because the system is executable early in the product’s life cycle. The fidelity of the system increases as stubs are instantiated, or prototype parts are replaced with complete versions of these parts of the software. This approach allows potential performance problems to be identified early in the product’s life cycle. These benefits reduce the potential risk in the project. 29  Improving Cost and Schedule Estimates One of the duties of an architect is to help the project manager create cost and schedule estimates early in the project life cycle. Top-down estimates are useful for setting goals and apportioning budgets. Cost estimations that are based on a bottom-up understanding of the system’s pieces are typically more accurate than those that are based purely on top-down system knowledge. Each team or individual responsible for a work item will be able to make more-accurate estimates for their piece than a project manager and will feel more ownership in making the estimates come true. The best cost and schedule estimates will typically emerge from a consensus between the top-down estimates (created by the architect and project manager) and the bottom-up estimates (created by the developers). 30  Transferable, Reusable Model Reuse of architectures provides tremendous leverage for systems with similar requirements. Not only can code be reused, but so can the requirements that led to the architecture in the first place, as well as the experience and infrastructure gained in building the reused architecture. When architectural decisions can be reused across multiple systems, all of the early- decision consequences are also transferred. A software product line or family is a set of software systems that are all built using the same set of reusable assets. Chief among these assets is the architecture that was designed to handle the needs of the entire family. The architecture defines what is fixed for all members of the product line and what is variable. The architecture for a product line becomes a capital investment by the organization. 31  Using Independently Developed Components Architecture-based development often focuses on components that are likely to have been developed separately, even independently, from each other. The architecture defines the elements that can be incorporated into the system. Commercial off-the-shelf components, open source software, publicly available apps, and networked services are example of interchangeable software components. The payoff can be Decreased time to market Increased reliability (widely used software should have its bugs ironed out already) Lower cost (the software supplier can amortize development cost across their customer base) Flexibility (if the component you want to buy is not terribly special purpose, it’s likely to be available from several sources, thus increasing your buying leverage) 32  Restricting Design Vocabulary As useful architectural patterns are collected, we see the benefit in voluntarily restricting ourselves to a relatively small number of choices of elements and their interactions. We minimize the design complexity of the system we are building. Enhanced reuse More regular and simpler designs that are more easily understood and communicated More capable analysis Shorter selection time Greater interoperability. Architectural patterns guide the architect and focus the architect on the quality attributes of interest in large part by restricting the vocabulary of design. Properties of software design follow from the choice of an architectural pattern. 33 Basis for Training The architecture documentation can serve as the first introduction to the system for new project members. Module views are excellent for showing someone the structure of a project Who does what, which teams are assigned to which parts of the system, and so forth. Component-and-connector views are excellent for explaining how the system is expected to work and accomplish its job. 34 Doing no architecture at all is often too risky for anything but the simplest projects. Would you want to drive over a bridge or ride in a jet that had not been carefully designed? Of course not. But you use software every day that is buggy, costly, insecure, unreliable, fault prone, and slow—and many of these undesirable characteristics can be avoided! 35 Life-Cycle Activities Software architecture design is one of the software architecture life-cycle activities. As in any software project life cycle, this activity is concerned with the translation of requirements into a design into an implementation. Specifically, the architect needs to worry about the following issues: 36 37  Architectural requirements. Among all the requirements, a few will have a particular importance with respect to the software architecture. These architecturally significant requirements (ASRs) include not only the most important functionality of the system and the constraints that need to be taken into account, but also—and most importantly—quality attributes such as high performance, high availability, ease of evolution, and iron- clad security. These requirements, along with a clear design purpose and other architectural concerns that may never be written down or may be invisible to external stakeholders, will guide you to choose one set of architectural structures and components over another. We will refer to these ASRs and concerns as drivers, as they can be said to drive the design. 38  Architectural design. Design is a translation, from the world of needs (requirements) to the world of solutions, in terms of structures composed of code, frameworks, and components. A good design is one that satisfies the drivers. Architectural design is the focus of course. 39  Architectural documentation. Some level of preliminary documentation (or sketches) of the structures should be created as part of architectural design. This activity, however, refers to the creation of a more formal document from these sketches. If the project is small and has a precedent, then architecture documentation may be minimal. In contrast, if the project is large, if distributed teams are collaborating, or if significant technical challenges exist, then architectural documentation will repay the effort invested in this activity. While documentation is often avoided and derided by programmers, it is a standard, non-negotiable deliverable in almost every other engineering discipline. If your system is big enough and if it is mission critical, it should be documented. In other engineering disciplines, a “blueprint”—some sort of documented design—is an absolutely essential step in moving toward implementation and the commitment of resources. 40  Architectural evaluation. As with documentation, if your project is nontrivial, then you owe it to yourself and to your stakeholders to evaluate it—that is, to ensure that the decisions made are appropriate to address the critical requirements. Would you deliver code without testing it? Of course not. Similarly, why would you commit enormous resources to fleshing out an architecture if you had not first “tested” the design? You might want to do this when first creating the system or when putting it through a major refactoring. Typically evaluation is done informally and internally, but for truly important projects it is advisable to have a formal evaluation done by an external team. 41  Architectural implementation/conformance checking. Finally, you need to implement the architecture that you have created (and evaluated). As an architect, you may need to tweak the design as the system grows and as requirements evolve. This is normal. In addition to this tweaking, your major responsibility during implementation is to ensure conformance of the code to the design. If developers are not faithfully implementing the architecture, they may be undermining the qualities that you have designed in. Again, consider what is done in other fields of engineering. When a concrete foundation for a new building is poured, the building that rests on top of that foundation is not constructed until the foundation has first been tested, typically via a core sample, to ensure that it is strong enough, dense enough, sufficiently impermeable to water and gases, and so forth. Without conformance checking, we have no way of ensuring the quality of what is being subsequently constructed. 42  The Role of the Architect. Role types Solution architects: A solution architect focuses primarily on identifying technological solutions to potential challenges a business encounters. They ensure the overall technical solution they create for a specific business problem fulfills the enterprises' requirements as well as end-user needs. Enterprise architects: For an enterprise architect, the main goal is usually to maintain and update a company's IT networks regularly and in the long term to ensure optimal performance. They analyze business needs to ensure the overall design and implementation align with the business goals. Data architects: They're responsible for defining procedures, policies, tools and models the software development team uses to create, organize, store and retrieve organizational data. Data architects also create standards for the collection, storage and migration of information from existing data structures or legacy systems. Cloud architects: Cloud architects are responsible for creating, designing, managing and executing the organization's cloud computing infrastructure. They develop and deploy applications to the cloud and keep track of cloud activities such as taking account43 of maintenance schedules and monitoring resource usage.  The Role of the Architect An architect is much more than “just” a designer. This role, which may be played by one or more individuals, has a long list of duties, skills, and knowledge that must be satisfied if it is to be successful. These prerequisites include the following: Defining and designing the software architecture for a project, including selecting the appropriate technologies, frameworks, and patterns to create a robust and scalable system. Collaborating with stakeholders, such as project managers, business analysts, and software developers, to understand and address their needs and requirements, ensuring that the software architecture aligns with the project's goals. 44  Ensuring that the software system is scalable, maintainable, and secure by making high-level design choices and setting technical standards for the project Providing technical leadership and guidance to software development teams, mentoring less experienced developers, and sharing knowledge on best practices and architectural principles. Evaluating and selecting third-party tools, libraries, and platforms that best suit the project's requirements while considering factors such as cost, performance, and compatibility. 45  Identifying and addressing potential technical risks and challenges, proactively assessing the system's architecture to identify any potential issues, and devising strategies to mitigate them Creating and maintaining comprehensive software architecture documentation, including design decisions, architectural patterns, and technical standards, to serve as a reference for the development team and other stakeholders throughout the product roadmap. Ensuring that the software architecture adheres to industry best practices and standards and continuously staying up-to-date with the latest trends and technologies to retain a competitive edge in the field 46 Thank you 47