1 / 51

Software Architecture

Software Architecture. Background. Any complex system is composed of sub-systems that interact While designing systems, an approach is to identify sub-systems and how they interact with each other SW Architecture tries to do this for software

eliora
Download Presentation

Software Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Architecture Software Architecture

  2. Background • Any complex system is composed of sub-systems that interact • While designing systems, an approach is to identify sub-systems and how they interact with each other • SW Architecture tries to do this for software • When designing such a system, therefore, the logical approach is to identify the subsystems that should compose the system, the interfaces of these subsystems, and the rules for interaction between the subsystems. This is what software architecture aims to do • A recent area, but a lot of interest in it Software Architecture

  3. Background… • Architecture is the system design at the highest level • Choices about technologies, products to use, servers, etc are made at arch level • Due to a wide range of options now available for how a system may be configured and connected, carefully designing the architecture becomes very important • Is the earliest place when properties like reliability or performance can be evaluated Software Architecture

  4. Role of Software Architecture • One of the most widely accepted definitions of software architecture is that the software architecture of a system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them • Arch is a design of the sw that gives a very high level view of parts and they relate to form the whole system • Partitions the sys in parts such that each part can be comprehended independently • And describes relationship between parts • A complex system can be partitioned in many diff ways, each providing a useful view • Same holds true of software also • There is no unique structure; many possible Software Architecture

  5. Architecture • Definition: Software arch is the structure or structures which comprise elements, their externally visible properties, and relationships among them • For elements only interested in external properties needed for relationship specification • Details on how the properties are supported is not important for arch • The defn does not say anything about whether an arch is good or not – analysis needed for it • An arch description describes the different structures of the system Software Architecture

  6. Key Uses of Arch Descriptions • Understandingand communication • To get a common understanding between the diff stakeholders (users, clients, architect, designer,…) • For negotiation and agreement • Arch descr can also aid in understanding of existing systems Software Architecture

  7. Uses… • Reuse • The, decision about using existing components is made at arch design time • Architecture also facilitates reuse among products that are similar and building product families such that the common parts of these different but similar products can be reused. Software Architecture

  8. Uses.. • Construction and evolution • Partitioning at arch level can be used for work allocation to teams as parts are relatively independent • Arch can help decide what is the impact of changes to existing components on others Software Architecture

  9. Uses… • Analysis • Sw arch opens various possibilities for software • E.g. reliability and performance of a system can be predicted from its arch, if estimates for parameters like load etc is provided Software Architecture

  10. Architectural Views • There is no unique arch of a sys • There are different views of a sw sys • A view consists of elements and relationships between them, and describes a structure • The elements of a view depends on what the view wants to highlight • Diff views expose diff properties(floor/elec/safety plan) • A view focusing on some aspects reduces its complexity Software Architecture

  11. Views… • In software, the different drawings are called views. A view represents the system as composed of some types of elements and relationships between them. • Different views expose different properties and attributes • A view describes a structure of the system. • Most of the proposed view belong to one of these three types • Module • Component and Connector • Allocation • The diff views are not unrelated – they all represent the same system Software Architecture

  12. Views… Module view • A sys is a collection of code units i.e. each implementing some part of the system functionality. • These views are code-based and do not explicitly represent any runtime structure of the system. • Examples of modules are packages, a class, a procedure, a method, a collection of functions, and a collection of classes. • The relationships between these modules are also code-based and depend on how code of a module interacts with another module. • Examples of relationships in this view are “is a part of” (i.e., module B is a part of module A), “uses or depends on” (a module A uses services of module B to perform its own functions and correctness of module A depends on correctness of module B), and “generalization or specialization” (a module B is a generalization of a module A). Software Architecture

  13. Views… • Component and Connector (C&C) • The system is viewed as a collection of runtime entities called components. • That is, a component is a unit which has an identity in the executing system. Objects (not classes), a collection of objects, and a process are examples of components. • Examples of connectors are pipes and sockets. Shared data can also act as a connector. If the components use some middleware to communicate and coordinate, then the middleware is a connector. • Connectors provide means of interaction between components, e.g. pipes, shared memory, sockets Software Architecture

  14. Views… Allocation view • An allocation view focuses on how the different software units are allocated to resources like the hardware, file systems, and people. That is, an allocation view specifies the relationship between software elements and elements of the environments in which the software system is executed. • They expose structural properties like which processes run on which processor, and how the system files are organized on a file system. • Expose structural properties like which process runs on which processor, which file resides where, … Software Architecture

  15. Views… • An architecture description consists of views of different types, with each view exposing some structure of the system. • Module views show how the software is structured as a set of implementation units, • C&C views show how the software is structured as interacting runtime elements, and • Allocation views show how software relates to non software structures. • These three types of view of the same system form the architecture of the system. • The C&C view is almost always done, and has become the primary view • We focus primarily on the C&C view Software Architecture

  16. Component and Connector View • Two main elements – components and connectors • Components: Computational elements or data stores • Connectors: Means of interaction between comps • The C&C view describes a runtime structure of the system – what comps exist at runtime and how they interact during execution • The C&C view is perhaps the most common view of architecture and most box-and-line drawings representing architecture attempt to capture this view Software Architecture

  17. Components • Components are generally units of computation or data stores in the system. • A component has a name, which is generally chosen to represent the role of the component or the function it performs. • A component is of a component type, where the type represents a generic component, defining the general computation and the interfaces a component of that type must have. • Examples of these types are clients, servers, filters, etc. Different domains may have other generic types like controllers, actuators, and sensors (for a control system domain). Software Architecture

  18. Some Component examples… Software Architecture

  19. Connectors • Interaction between components may be through a simple means supported by the underlying process execution infrastructure of the operating system. • For example, a component may interact with another using the procedure call mechanism (a connector), which is provided by the runtime environment for the programming language. • Examples of such mechanisms are remote procedure call, TCP/IP ports, and a protocol like HTTP • Connectors need not be binary and a connector may provide an n-way communication between multiple components. • For example, a broadcast bus may be used as a connector, which allows a component to broadcast its message to all the other components. Software Architecture

  20. Connector examples Software Architecture

  21. An Example • Design a system for taking online survey of students on campus • Multiple choice questions, students submit online • When a student submits, current result of the survey is shown • Is best built using web; a 3-tier architecture is proposed • Has a client, server, and a database components (each of a diff type) • Connector between them are also of diff types Software Architecture

  22. Example… It consists of a client which will display the form that the student can complete and submit, and will also display the results. The second component is the server, which processes the data submitted by the student, and saves it on the database, which is the third component. The server also queries the database to get the outcome of the survey and sends the results in proper format (HTML) back to the client, which then displays the result. Software Architecture

  23. Example… • At arch level, details are not needed • The connectors are explicitly stated, which implies that the infrastructure should provide http, browser, etc. • The choice of connectors imposes constraints on how the components are finally designed and built Software Architecture

  24. Extension 1 • This arch has no security – anyone can take the survey • We want that only registered students can take the survey (at most once) • Need a authentication server • Need to use cookies, … • and server has to be built accordingly (the connector between server and auth server is http with cookies) Software Architecture

  25. Extension 1… Software Architecture Java Database Connectivity

  26. Extension 2 • It was found that DB is frequently down • For improving reliability, want that if DB is down, student is given an older survey result and survey data stored • The survey data given can be outdated by at most 5 survey data points • For this, will add a cachecomponent, which will store data as well as results Software Architecture

  27. Extension 2… Software Architecture

  28. Example… • One change increased security, 2nd increased performance and reliability • I.e. Arch level choices have a big impact on system properties • That is why, choosing a suitable arch can help build a good system Software Architecture

  29. Architectural Styles for C&C View • An arch style defines a family of archs that satisfy the constraint of that style • Styles can provide ideas for creating arch for a sys; they can be combined also • We discuss a few common styles Software Architecture

  30. Pipe and filter • Pipe-and-filter style of architecture is well suited for systems that primarily do data transformation whereby some input data is received and the goal of the system is to produce some output data by suitably transforming the input data. • A system using pipe-and-filter architecture achieves the desired transformation by applying a network of smaller transformations and composing them in a manner such that together the overall desired transformation is achieved. • A filter performs a data transformation, and sends the transformed data to other filters for further processing using the pipe connector. In other words, a filter receives the data it needs from some defined input pipes, performs the data transformation, and then sends the output data to other filters on the defined output pipes. Software Architecture

  31. Pipe and filter • Well suited for systems that mainly do data transformations • A system using this style uses a network of transforms to achieve the desired result • Has one component type – filter • Has one connector type – pipe • A filter does some transformation and passes data to other filters through pipes Software Architecture

  32. Pipe and Filter… • A filter is independent; need not know the id of filters sending/receiving data • A pipe is unidirectional channel which moves streams of data from one filter to another • Pipes have to perform buffering, and synchronization between filters Software Architecture

  33. Example • A system needed to count the frequency of different words in a file • One approach: first split the file into a sequence of words, sort them, then count the #of occurrences • The arch of this system can naturally use the pipe and filter style Software Architecture

  34. Example.. This architecture proposes that the input data be first split into a sequence of words by a component Sequencer. This sequence of words is then sorted by the component Sorting, which passes the output of sorted words to another filter (Counting) that counts the number of occurrences of the different words. Software Architecture

  35. Shared-data style • Components of data repository type are where the system stores shared data—these could be file systems or databases. • These components provide a reliable and permanent storage, take care of any synchronization needs for concurrent access, and provide data access support. • Components of data accessors type access data from the repositories, perform computation on the data obtained, and if they want to share the results with other components, put the results back in the depository. • In other words, the accessors are computational elements that receive their data from the repository and save their data in the repository as well. Software Architecture

  36. Shared-data style • Two component types – data repository and data accessor • Data repository – provides reliable permanent storage • Data accessors – access data in repositories, perform computations, and may put the results back also • Communication between data accessors is only through the repository Software Architecture

  37. Shared-data style… • Two variations possible • Black board style: if data is posted in a repository, all accessors are informed; i.e. shared data source is an active agent • Repository style: passive repository • Eg. database oriented systems; web systems Software Architecture

  38. Example • A student registration system of a university • Repository contains all the data about students, courses, schedules,… • Accessors like admin, approvals, registration, reports which perform operations on the data Software Architecture

  39. Example… The system clearly has a central repository which contains information about courses, students, prerequisites, etc. It has an Administrator component that sets up the repository, rights to different people, etc. The Registration component allows students to register and update the information for students and courses. The Approvals component is for granting approvals for those courses that require instructor’s consent. The Reports component produces the report regarding the students registered in different courses at the end of the registration. The component Course Feedback is used for taking feedback from students at the end of the course. Software Architecture

  40. Client-Server Style • Two component types – clients and servers • Clients can only communicate with the server, but not with other clients • Communication is initiated by a client which sends request and server responds • One connector type – request/reply • Often the client and the servers reside on different machines Software Architecture

  41. Client-server style… • A general form of this style is the n-tier structure • A 3-tier structure is commonly used by many application and web systems • Client-tier contains the clients • Middle-tier contains the business rules • Database tier has the information Software Architecture

  42. Some other styles • Publish-subscribe style • Some components generate events, and others subscribe to them • On an event, those component that subscribe to it are invoked • Peer-to-peer style • Like object oriented systems; components use services from each other through methods • Communication processes style • Processes which execute and communicate with each other through message passing Software Architecture

  43. Architecture and Design • Both arch and design partition the system into parts and their org • What is the relationship between design and arch? • Arch is a design; it is about the solution domain, and not problem domain • Can view arch as a veryhigh level design focusing on main components • Design is about modules in these components that have to be coded • Design can be considered as providing the low level module view of the system Software Architecture

  44. Preserving the Integrity of Architecture • What is the role of arch during the rest of the development process? • Many designers and developers use it for understanding but nothing more • Arch imposes constraints; the implementation must preserve the arch. • I.e. the arch of the final system should be same as the arch that was conceived Software Architecture

  45. Documenting… • An arch document should contain • System and architecture context • Description of architecture views • Inter-view documentation • A context diagram that establishes the sys scope, key actors, and data sources/sinks can provide the overall context • A view description will generally have a pictorial representation, as discussed earlier Software Architecture

  46. Documenting… • Inter-view documentation • Views are related, but the relationship is not clear in the view • This part of the doc describes how the views are related (eg. How modules are related to components) • Rationale for choosing the views • Any info that cuts across views Software Architecture

  47. Evaluating Architectures • Arch impacts non-functional attributes like modifiability, performance, reliability, portability, etc • Arch plays a much bigger impact on these than later decisions • So should evaluate a proposed arch for these properties • Q: How should this evaluation be done? • Many different ways Software Architecture

  48. Evaluating Architectures… • Procedural approach – follow a sequence of steps • Identify the attributes of interest to different stakeholders • List them in a table • For each attribute, evaluate the architectures under consideration • Evaluation can be subjective based on experience • Based on this table, then select some arch or improve some existing arch for some attribute Software Architecture

  49. Summary • Arch of a sw system is its structures comprising of elements, their external properties, and relationships • Arch is a high level design • Three main view types – module, component and connector, and allocation • Component and connector (C&C) view is most commonly used Software Architecture

  50. Summary… • There are some C&C styles that are commonly used, e.g. pipe-and-filter, shared data, client server,.... • An arch description should document the different views and their relationship – views can be combined • Rationale and other supporting information should also be captured Software Architecture

More Related