Software architecture Unit 1 notes

Software architecture Unit 1 notes

• 1.
  SOFTWARE ARCHITECTURE (Unit– I) Introduction The Architecture Business Cycle: Where do architectures come from? Software processes and the architecture business cycle; what makes a “good” architecture? What software architecture is and what it is not; other points of view; Architectural patterns, reference models and reference architectures; Importance of software architecture; Architectural structures and views. 1.1 Where Do Architectures Come From  An architecture is the result of a set of business and technical decisions.  The requirements make explicit some—but only some—of the desired properties ARCHITECTURES ARE INFLUENCED BY  SYSTEM STAKEHOLDERS o Stakeholders have different concerns (which may be contradictor) o Having an acceptable system involves properties such as  performance  reliability  availability  platform compatibility  memory utilization
• 2.
   network usage security  modifiability  usability  interoperability with other systems o Often requirements document do not cature these properties well enough o Architects must identify and actively engage stakeholders early in the life cycle to  understand the real constraints of the system  manage the stakeholders’ expectations  negotiate the system’s priorities  make tradeoffs o Architects need more than just technical skill: diplomacy, negotiation, and communication skills are essential  THE DEVELOPING ORGANIZATION o An architecture is influenced by the structure or nature of the development organization  immediate business investment (eg. existing architecture)  long-term business investment (eg. long term infrastructure)  organizational structure (e.g. subcontracting, skills of employes)  THE BACKGROUND AND EXPERIENCE OF THE ARCHITECTS o What worked in the past and what not o Education, training, exposure to architectural patterns o wish to experiment with something new  THE TECHNICAL ENVIRONMENT o practices and techniques of the professional community THE ARCHITECTURES (can) AFFECTS (Feedback loop)  The structure of THE DEVELOPING ORGANIZATION o Units of implemented software drives development project's and team structure  The goals of THE DEVELOPING ORGANIZATION o Successful system -> establish a foothold in a particular market area.  Stakeholder requirements for the next system when it is based on the curent system  THE ARCHITECT'S EXPERIENCE  A few system will influence the software engineering culture
• 3.
  1.2 Software Processesand the Architecture Business Cycle Architecture Activities:  Creating the Business Case for the system o Product cost? o Target market? o Time to Market? o Interface with other systems o System limitation  Understanding the requirements o Is the system a variation of an existing system? o Prototype may help to understand the requirements o It is not until the architecture is created that some trade-offs among requirements become apparent and force a decision on requirements priorities.  Create or Selecting the Architecture o The conceptual integrity is the key to sound system design o Conceptual integrity can only be had by a small number of minds  Communicating the architecture o Architecture must be communicated clearly and unambiguously to all of the stakeholders (incl. developers, testers and management) o Documentation  Analyzing or Evaluating the Architecture o Choosing among candidate designs  Implementing Based on the architecture o Environment/Infrastructure that assist developer in creating and maintaining the architecture  Ensuring Conformance to an Architecture
• 4.
  1.3 What Makesa "Good" Architecture?  An architecture fits more or less for some stated purpose  An architecture can only be evaluated in the context of specific goals Process rules of thumb  The architecture should be the product of a single architect or a small team with an identified leader  The architect (team) should have the functional requirments and quality attributes (prioritized)  The architecture should be well documented  The architecture should be reviewed with the stakeholders  The architecture should be evaluated for quality attributes  The architecture should lend to incremental implementation (via the creation of a "skeletal" system)  The architecture should result in a specific set of resource contention areas. The resolution of which is clearly specified, circulated ans maintained. Structural rules of thumb  Well defined modules whose functional responsibilities are allocated on the principles of o information hiding (including abstraction of computing infrastructure) o separation of concern  Each module should have a well-defined interface o Hides changeable aspects o allows the development teams to work independently  Quality attributes should be achieved using well-known architecture tactics specific to each attribute  If a architecture depends upon a commercial product, it should be structured such that changing to a different product is inexpensive.  Creating / Consumption of data should be separated in different modules  Parallel-Processing modules: Well defined processes or tasks that do not necessarily mirror the module decomposition  Task/Process assignment to processor should be changeable  The architecture should feature a small number of simple interaction patterns
• 5.
  2.1 What SoftwareArchitecture Is and What It Isn't Definition: The software architecture of a program or computing system is the structure or structures of the system, which comprise o software elements, o the externally visible properties of those elements, o and the relationships among them. “Externally visible” properties are those assumptions other elements can make of an element, such as its  provided services  performance characteristics,  fault handling,  shared resource usage,  and so on. implications of this definition:  Architecture defines software elements o how the elements relate to each other o 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. (only public part)  Systems comprise more than one structure o no one structure can claim to be the architecture o Relationships and elements might be  runtime related ("send data", processes)  nonruntime related ("sub model of", "inherits from", class)  Every computing system with software has a software architecture o it does not necessarily follow that the architecture is known to anyone. o An architecture can exist independently of its description or specification  The behaviour of each element is part of the architecture o allows elements to interact with each other o Add specification and properties to the elements and relationships  The definition is indifferent as to whether the architecture for a system is a good one or a bad one o Evaluating the SW architecture in the context of use.
• 6.
  2.3 Architectural Patterns,Reference Models, and Reference Architectures  Architectural Pattern: A description of element and relation types together with a set of constraints on how they may be used. o A set of constraints on an architecture o Define a set or family of architectures o An architectural pattern is not an architecture o Exhibit known quality attributes o Often the architect’s first major design choice o "Architectural style" has also been widely used o Example: "Client-Server"  Reference Model: A division of functionality together with data flow between the pieces. o Standard decomposition of a known problem into parts that cooperatively solve the problem. o characteristic of mature domains o Example: Compiler; database management system  Reference Architecture A reference model mapped onto software elements (that cooperatively implement the functionality defined in the reference model) and the data flows between them. o Whereas a reference model divides the functionality, a reference architecture is the mapping of that functionality onto a system decomposition.  Reference models, architectural patterns, and reference architectures are not architectures; they are useful concepts that capture elements of an architure.  Each is the outcome of early design decisions.
• 7.
  2.4 Why IsSoftware Architecture Important?  Communication among stakeholders o Every stakholder has different concerns; SW Architecture can be used as a basis for mutual understanding, negotiation, consensus, and communication among stakeholders.  Early design decisions o Software architecture manifests the earliest design decisions, these decision are  the most difficult to get correct and  the hardest to change later o The Architecture Defines Constraints on Implementation  Implementation must conform to  prescribed design decisions  resource allocation decisions  Architectures are both prescriptive and descriptive o The Architecture Dictates Organizational Structure.  work breakdown structure  work assignments to teams  plans, schedules, budgets  communication channels among teams  dependency and coupling important for work assignement  As soon as the work packages are assigned to teams or subcontracters, it is "freezed" and can no longer be changed easily o The Architecture Inhibits or Enables a System’s Quality Attributes. o Architecture allows to predict system quality attributes without waiting until the system is developed or deployed o The Architecture Makes It Easier to Reason about and Manage Change  Three kind of changes: local, nonlocal, and architectural o The Architecture Helps in Evolutionary Prototyping  An Architecture can be analyzed and prototyped as skeletal system. This helps in two ways  The system is executable early in the product’s life cycle. Elements can be replaced step by step  potential performance problems can be identified early o The Architecture Enables More Accurate Cost and Schedule Estimates  Estimations based on system pieces are more accurate  The architecture work results in review and validation of the requirements  Transferable abstraction of a system  SW architecture constitutes a (relatively small) model that is transferable across similar systems  Software architecture can serve as the basis for reuse of  requirements  development-support artifacts (templates, tools, etc.)  code / components  experience o Software Product Lines Share a Common Architecture  Set of software-intensive systems sharing a common, managed set of features
• 8.
   powerful approachto multi-system development that shows order-of-magnitude payoffs in time to market, cost, productivity, and product quality o Systems Can Be Built Using Large, Externally Developed Elements  composing or assembling elements that are likely to have been developed separately, even independently, from each other  COTS components, subsystems, and compatible communications interfaces all depend on the principle of interchangeability  achitectural mismatch: if subsystems have been built with conflicting architectural assumptions o Less Is More: It Pays to Restrict the Vocabulary of Design Alternatives  restricting to a relatively small number of choices when it comes to program cooperation and interaction  Advantages: enhanced re-use, more regular and simpler designs that are more easily understood and communicated, more capable analysis, shorter selection time, and greater interoperability o An Architecture Permits Template-Based Development  Templates can be used to capture in one place the inter-element interaction mechanisms. o An Architecture Can Be the Basis for Training
• 9.
  2.5 Architectural Structuresand Views  Definition o View A representation of a set of elements and the relations among them. o Structure The set of elements itself, as they exist in software or hardware  Restrict our attention at any one moment to one (or a small number) of the software system’s structures.  To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment SOFTWARE STRUCTURES  Module structures Elements are modules, which are units of implementation. * 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? o Decomposition * shows how larger modules are decomposed into smaller ones recursively o Uses * The units are: modules, procedures or resources on the interfaces of modules * The units are related by the uses relation o Layered * "uses relations" structured into layers o Class, or generalization * shows the “inherits-from” or “is-an-instance-of” relations among the modules  Component-and-connector structures Elements are runtime components (units of computation) and connectors (communication vehicles among components) The relation is attachment, showing how the components and connectors are hooked together * What are the major executing components and how do they interact? * What are the major shared data stores? * Which parts of the system are replicated?
• 10.
  * How doesdata progress through the system? * What parts of the system can run in parallel? * How can the system’s structure change as it executes? o Process, or communicating processes * units are processes or threads that are connected with each other by communication, synchronization, and/or exclusion operations o Concurrency * The units are components and the connectors are “logical threads” * A logical thread is a sequence of computation that can be allocated to a separate physical thread o Shared data, or repository * This structure comprises components and connectors that create, store, and access persistent data o Client-server * The components are the clients and servers, and the connectors are protocols and messages  Allocation structures the relationship between the software elements and the elements in one or more external environments * What processor does each software element execute on? * In what files is each element stored during development, testing, and system building? * What is the assignment of software elements to development teams? o Deployment * Shows how software (usually a process from a component-and-connector view) is assigned to hardware-processing and communication elements * Relations are “allocated-to” and “migrates-to” if the allocation is dynamic o Implementation * how software elements (usually modules) are mapped to the file structure(s) o Work assignment * assigns responsibility for implementing and integrating the modules to development teams RELATING STRUCTURES TO EACH OTHER  Elements of one structure are related to elements of other structures  Often the dominant structure is module decomposition, because it spawns the project structure  Structures represent a powerful separation-of-concerns approach for creating the architecture  Structures are basis for architecture documentation