Introduction to Software Architecture PDF

Chapter 1 Introduction to software architecture  What is Software Architecture? Where does Software Design sit in the whole Software Development Life Cycle(SDLC)? Software Architecture: Bridging...

Chapter 1 Introduction to software architecture  What is Software Architecture? Where does Software Design sit in the whole Software Development Life Cycle(SDLC)? Software Architecture: Bridging Software Agenda! We are Requirement and Software Implementation going to cover:- Architecture Design Looks Architecture Styles Quality Attributes Software Architecture Design Guidelines  “Software Architecture is all about structure and vision.” Simon Brown What is Where; Application Structure: emphasis on how you Software divide your software application. Architecture? While; Application Vision: emphasis on how your application will response to future changes. Which is the role of software architect to make future changes easy-to-change. This point also subject to non-functional requirement such as reliability and scalability. Con… According to the Book of Software Architecture in Practice (third edition), Defined Software Architecture as: A set of structures needed to reason about the system, which comprise elements, relations among them, and properties of both. Where does Software Design sit in the whole Software Development Life Cycle(SDLC)? Figure 1.1 Software Development Life Cycle SDLC Software Architecture: Bridging Software Requirement and Software Implementation Software architecture plays a very important role in software development. It is a blueprint guidelines for developing a large and complex software system based on the Software Requirements Specification (SRS ). Software Architecture highlights early design decisions that have a decisive impact on the ultimate success of software products. Software Architecture covers the software functional requirements and non-functional requirements. Software Architecture shows how the system is structured and how its components work together, as depicted in the following slide. Architectural design looks Figure 1.2 Box-and-Line diagram showing sub-systems Sub-system also called elements, which plays a sole responsibility such as interface presentation, data gathering, business logic. It performs function required by the system. Connectors that enables communication, coordination, cooperation among elements and components. Constraints that define how elements can be integrated to form the system.  Data flow styles: Batch Sequence, Pipe & Filter, Process Control. Data Centered: Repository, Blackboard. Architecture Object-Oriented. Styles Hierarchy: Layered, Virtual Machine, Main/Subroutine. (Patterns) Distributed: Multi-tier, Client/Server. Asynchronous Communication: Event-Based, Buffered Messaging. Interaction Oriented: MVC, PAC.  Each architecture design has its advantages, disadvantages and potential risk. Quality Choosing the right architecture style to satisfy required quality attributes is very important in addition to function satisfaction. Attributes Quality attributes are identified in the requirement analysis process. Quality attributes are non-functional requirements and represent the architectural constraints of the system. It describes the intended behaviors of a system and measure its suitability.  1. Implementation attributes (Not observable at run time) Quality Interoperability – the universal accessibility and the ability to exchange data with internal components and outside world. Attributes are categorized Maintainability & extensibility – the ability to be fixed and extended conveniently. into three Testability – the degree to which the system facilitates the categories: establishment of test cases, and low risk of bugs and faults. It usually requires a complete set of documentation accompanied with system design and implementation. Scalability – the ability to adapt to the increase of user requests volume. Flexibility – The ease of modification of a system to cater to the environment or problems that the system is originally not design for. Con… Runtime attribute (observable at runtime) Availability – the ability of a system to be available 24/7 days. Security – the ability to prevent malicious attacks from outside or inside of the system. Performance – it usually includes times efficiency and resource efficiency, which most of the time conflict with each other, according to theory of computation. Useability – it usually includes the completeness of software, correctness, compatibility, and user-friendliness. Con.. Business attributes Time to market: the time it takes from requirement analysis to the date product is released. Cost: expense of the project. Lifetime: the period of time that the product is alive. Software Architecture Design Guidelines 1. Think of what to do before think of how to do it. All functional and non-functional requirements should be identified, verified, and validated before the overall and detailed design. Using the abstract architecture design of a system to communicate with stakeholders help avoid overhauling the system design in later stage of the software development cycle. A successful analysis design relies on a successful and accurate requirement analysis. Note: Different stakeholders of software system have their different concerns, such as: ❖ Software Architects have to make sure what are needed and what can be traded off. ❖ Investors of the software project are usually concerned with system release date, budget, usability, etc.. ❖ Software developers focus on the implementation and are concerned with whether the software design is detailed enough for coding. ❖ Software project managers may be concerned with software architecture evolution and maintenance in the future  2. Think of non-functional requirements as early as possible. Should consider non-functional requirements while mapping functional requirement to architecture design. Communicate with stakeholders and document their preferences of quality attribute. Its not possible to find a design meeting all quality attributes. Thus, tradeoff is Con.. required. 3. Think of software reusability and extensibility. For most software systems, it is very likely that new functionalities will be added after they are deployed. Reuse existing software components to increase reliability and cost effectiveness of new system. Con.. 4. Try to promote the high cohesion within each element and loose coupling between elements. For example, in OO design if a class is assigned to bear two unrelated responsibilities, it is regarded as incoherent. A similar concern is that each architecture style should show a very clear division lines between elements to guarantee loose-coupling. In most cases, loose coupling means less interdependency between components. Hence, the change of one component will not likely to cause ripple-changes of other component. 5. Tolerate refinement of design Never expect to have software design completed perfect within one step. 6. Avoid ambiguous design and over-detailed design Ambiguous design lacks constraints and over-detailed design restricts implementation. Software Architecture Design Space  The architect responsibilities: Architect is responsible for proposing a concrete software architecture to best support the detailed design and implementation of a software project. Architect must know what design alternatives are available to him, and which one supports the Overview functional and non-functional project requirement specification better. “Software Architect must understand his software architecture design space”  Basically, software architecture is a set of software elements connected by a set of connector. A software element can be a process, an object, an instance of a software component, or a service. “Different software elements may run on different Con.. hardware and software platform and be implemented in different programing language or on different software frameworks.” Also “Two software elements can run in the same process, on the same computer system, within an intranet, or distributed over the internet.” Con.. Thus, depending on their relative location, the connectors between a pair of software elements can be implemented in various forms, includes: Local method invocations Remote method invocation Service calls Messaging through a message Queue “Connectors can work in different modes including synchronous and asynchronous.” Types of Software Structure A software architecture can be described with various software structures, each from different perspective. Software code structure A software project is implemented in multiple source file. During the deployment a project includes many static file types including executable files, library files, binary software component modules, deployment descriptors and other resource files. At software development time, the main software elements are source code modules or files. Each of these software modules will assigned functional and non-functional attributes, and public APIs will be defined for each module to separate the interfaces and implementations of a module. The connector at this level are in the form of module dependency. Module A is connected to module B if and only if A needs to invoke some method in module B during execution.  Such connectors have attributes including the following: Direction: If module A invokes a method of module B during execution, then there is a unidirectional connector from module A to module B. Con.. Synchronization: A method invocation can be synchronous or asynchronous. Sequence: Some connector must be used in particular sequence.