Software Architecture by: Software Architecture by Prof. T. Arivanantham Unit - I: Unit - I Introductions Architecture Business cycle What is software architecture why software architecture is important, documenting software architectures. Software Architecture: Software Architecture The SA of a program or computing system is the structure or structures of the systems, which comprise software elements, the externally visible properties of those elements, and the relationships among them. An architecture is the result of a set of technical, business and social influences. Software Architecture: Software Architecture SA is a result of technical, business and social influences. Its existence in turn affects the above environments that subsequently influence future architectures. This cycle of influence is called Architecture Business Cycle(ABC). Architecture: Architecture Factors Influencing Architectures: Factors Influencing Architectures Many people and organizations are interested in the construction of a software system is called as “Stake holders “ Architectures are influenced by • stakeholders of a system • technical and organizational factors • architect’s background PowerPoint Presentation: Low Cost, Keeping people employed, leveraging existing corporate assets ! Neat features, short time to market, low cost, parity with competing products ! Behavior, performance, security, reliability ! Modifiability Low cost, timely delivery, not changed very often ! Stakeholders of a system 7 Development Organization Management Marketing End-user Maintenance organization customer Development Organization Concerns: Development Organization Concerns Business issues • investing in, and then amortizing the infrastructure • keeping cost of installation low • investing in, and then utilizing personnel Organizational structure issues • furthering vested interests, e.g., - maintaining an existing database organization - supporting specialized expertise • maintaining the standard method of doing business Architect’s Background: Architect’s Background Architects develop their mindset from their past experiences. • Prior good experiences will lead to replication of prior designs. • Prior bad experiences will be avoided in the new design. Technical Environment:
Technical Environment Current trends: today’s information system will likely employ a • database management system •
for delivery and distribution across platforms This was not true 10 years ago. Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.
Ramification of influences on an Architecture:
Ramification of influences on an Architecture Architects need to know and understand the nature, source, and priority of constraints on the project as early as possible. They must identify and actively engage the stakeholders to solicit their needs and expectations. Delaying the project and idling workers. Basic Skill: The architects need more than just technical skills. Diplomacy, negotiation and
PowerPoint Presentation: Influences on the Architecture Architecture System Stakeholders Developing Organization Technical Environment Architect’s Experience Architect Requirements (Qualities) Architect’s Influences 12 PowerPoint Presentation: Architecture System Stakeholders Developing Organization Technical Environment Architect’s Experience Architect Requirements (Qualities) Architect’s Influences Architecture Business Cycle 13 S/W Processes and the ABC: S/W Processes and the ABC Create the business case for the system. Product cost, targeted market, time to market, interface with other system, system limitations. Understand the requirements. Use cases State Machine Prototyping Qualities Create or select the architecture. Represent and communicate the architecture. S/W Processes and the ABC: S/W Processes and the ABC Analyze or evaluate the architecture. Architecture Tradeoff Analysis Method (ATAM) Cost Benefit Analysis Method (CBAM) Implement the system based on the architecture. Build Well communicated architecture Ensure the implementation conforms to the architecture. Constant monitoring is required to ensure that the actual architecture and its representation is faithful to each phase. What Makes a Good Architect?: What Makes a Good Architect? People skills: must be able to • negotiate competing interests of stakeholders • promote inter-team collaboration Technical skills: must understand • The relationships between qualities and structures • Current technology • Most requirements for an architecture are not written down in any requirements document Communication skills: must be able to • clearly convey the architecture to teams (both verbally and in writing) • listen to and understand multiple viewpoints Architecture Process Guidelines: Architecture Process Guidelines Single architect or small group with identified leader. Must have system technical requirements and articulated, prioritized qualitative properties. Architecture must be well-documented using an agreed-on notation that all can understand. Architecture should be actively reviewed by all stakeholders. Architecture Process Guidelines: Architecture Process Guidelines Analyze architecture for applicable quality measures and formally review early in process. Architecture should allow creation of a skeletal system on which functionality can incrementally grow. Architecture should result in specific resource restriction/allocation models (memory, bandwidth, time). Architecture Process Guidelines: Architecture Process Guidelines Well-defined functional modules using information hiding, separation of concerns, and well-defined interfaces. Module separation of concerns should allow concurrent, relatively independent development by separate teams. Quality attributes should be achieved using well-known architectural tactics specific to each attribute. Never depend on a particular version of a commercial product or tool; make change straightforward and inexpensive. Architecture Process Guidelines: Architecture Process Guidelines Separate data producers from data consumers. Parallel processing: well-defined processes and tasks that may not mirror module structure. Process or task assignment to processors must be easily changed, even at run-time. Consistently use a small number of simple interaction patterns. What SA Is and What it isn’t Typical, but uninformative, presentation of a software architecture: What SA Is and What it isn’t Typical, but uninformative, presentation of a software architecture What SA Is and What it isn’t: What SA Is and What it isn’t What is the nature of the elements? What are the responsibilities of the elements? What is the significance of the connections? What is the significance of the layout? Some of the implication of SA: Some of the implication of SA Architecture defines software elements: the architecture embodies information about how the elements relate to each other. This means that it specifically omits certain information about elements that does not pertain to their interaction. An architecture is foremost an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to or interact with other elements. Some of the implication of SA: Some of the implication of SA Systems can and do comprise more than one structure. Every computing system with software has a SA. The behavior of each elements is part of the architecture Whether the architecture for a system is a good one or a bad one. Some of the implication of SA: Some of the implication of SA Architecture is high level design. Architecture is the overall structure of the system. Architecture is the structure of the components of a program or system. Architecture is components and connectors. Architecture Patterns, Reference Models & Reference Architectures: Architecture Patterns, Reference Models & Reference Architectures An Architecture pattern is a description of elements & relation types together with a set of constraints on how they may be used. A reference model is a division of functionality together with data flow between the pieces. A reference Architecture is a reference model mapped onto software elements and the data flows between them. The Relationships of reference models, architecture patterns, reference architectures and software architectures. (The arrow indicate tha subsequent concepts contain more design elements.): The Relationships of reference models, architecture patterns, reference architectures and software architectures. (The arrow indicate tha subsequent concepts contain more design elements.) Reference Model Architectural Patten Reference Architecture Software Architecture Why is SA important: Why is SA important Fundamentally three reasons for SA important: Communication among stakeholders. (Architecture is the vehicle for stakeholder communication) Early design decisions. Transferable abstraction of a system Architecture Early design decisions: Architecture Early design decisions It defines constraints on implementation. It dictates organizational structure. It inhibits or enables a system quality attributes. It should predicting system quality by studying the Architecture. It makes it easier to Reason about and manage change. It helps in Evolutionary Prototyping. It enables more Accurate Cost and Schedule Estimates. Transferable abstraction of a system: Transferable abstraction of a system Software product lines share a common architecture. Systems can be built using large, Externally Developed Elements. Less is More: it Pays to restrict the vocabulary of design alternative. Architecture permits Template Based Development. Architecture can be the Basis for Training Architectural Structure and Views : Architectural Structure and Views It divide into three groups depending on the board nature of the elements they show. Module structure: What is primary functional responsibility assigned What other s/w elements allowed to use What other s/w does it actually use What module are related to other module by specialization Component and connector structure: Allocation structure: Software structures: Software structures Decomposition: “ is a sub module of “ relation. How larger modules are decomposed into smaller ones to easily understood. Uses: resources on the interfaces of modules. Layered: layer is a coherent set of related functionality. It hide implementation specifics below form the layers above. Class or generalization: the relation is “inherits-form” or “is-an-instance-of”. Software structures: Software structures Client-Server: they share to carry out the systems work, useful for separation of concerns, physical distribution & load balancing. Concurrency: allows the architect to determine opportunities for parallelism and the location where resource contention may occur. Process or communication process: is important in helping to engineer a systems execution performance and availability. Shared data: it create, store & access persistent data. To ensure good performance & data integrity. Software structures: Software structures Deployment: shows how software is assigned to hardware processing and communication elements. Implementation: how software elements are mapped to the file structure in the system’s development. Work Assignment: this structure assign responsibility for implementing & integrating the modules to the appropriate development teams. Best Software Architecture: Best Software Architecture Relating structures to each other Which structures to choose Logical Process Development Physical