Presentation is loading. Please wait.

Presentation is loading. Please wait.

University of Southern California Center for Systems and Software Engineering CS577a: Elements of Software Architecture 09/28/2009 1 © USC-CSSE 2005-2009.

Similar presentations


Presentation on theme: "University of Southern California Center for Systems and Software Engineering CS577a: Elements of Software Architecture 09/28/2009 1 © USC-CSSE 2005-2009."— Presentation transcript:

1 University of Southern California Center for Systems and Software Engineering CS577a: Elements of Software Architecture 09/28/ © USC-CSSE David Klappholz, Nupul Kukreja

2 University of Southern California Center for Systems and Software Engineering Agenda Introduction to some of the architectural styles/patterns along with an emphasis on those applicable for CS577 projects Component and connector (C&C) analysis for the architectural elements Mapping of the C&C diagrams to an architecture to obtain the ‘Element-Relationship’ Diagram – documented in the OCD Introducing the deployment perspective of the system 09/28/2009© USC-CSSE

3 University of Southern California Center for Systems and Software Engineering Software Architecture* A software system’s architecture is the set of principal design decisions made about the system* –‘Principal’ implies a degree of importance that grants the decision ‘architectural status’. For example: The system must handle at least 5000 users, implies ‘scalability’ to be an ‘architectural decision’ –Some decisions are NOT architectural. For example: choice of algorithm etc., 09/28/2009© USC-CSSE *Source: Software Architecture: Foundations, Theory & Practice – Richard N Taylor et al.

4 University of Southern California Center for Systems and Software Engineering Software Architecture: Points to Remember The ‘choice’ of an architectural style imposes certain constraints on the architecture These constraints are primarily geared towards ‘how’ do the architectural elements interact with each other and in what ways (This will be elaborated later when explaining the various styles/patterns) There is NO “one size fits all” approach to architecting – the architectures are usually ‘hybrid’ to combined to achieve various qualities/attributes 09/28/2009© USC-CSSE

5 University of Southern California Center for Systems and Software Engineering The need for an Architecture Defining an architecture gives a ‘structure’ to an application It imposes certain restrictions on the interaction of the various components to help provide cleaner interfaces and increase modularity (i.e., Increasing cohesion and decreasing coupling) Helps make the application more amenable to change and maintainable – if and only if the architectural decisions are NOT violated Provides ‘tangible’ proof early, on the ‘feasibility’ of implementing the software system 09/28/2009© USC-CSSE

6 University of Southern California Center for Systems and Software Engineering Architectural Styles/Patterns Good software design requires that the first step be a choice of an appropriate architectural style or pattern. (The distinction between “style” and “pattern” in software architecture is more subtle than we need to discuss here.) Like all other choices in software development, developers often make a choice and later have to refine or change it as they learn more about the project at hand. On the next few slides we discuss four popular architectural styles/patterns and their variations – there are many more, and there are even entire courses on Software Architecture – one of which (style/pattern) is typically appropriate for most projects in this course. 09/28/ © USC-CSSE

7 University of Southern California Center for Systems and Software Engineering Star Topology An architecture that has the form shown below is said to have a “star topology.” DaDA Central Component component_11 … component_12component_1n component_21component_22component_2m 09/28/ © USC-CSSE …

8 University of Southern California Center for Systems and Software Engineering Sense, Compute, Control Style The example of the Star Topology architectural style shown on the next slide is called the Sense, Compute, Control style. Domains in which the Sense, Compute, Control style is frequently appropriate are simple embedded systems that interact with the environment, e.g., robots The Sense, Compute, Control style may be appropriate for a few course projects that have been done over the past decade, but very few. 09/28/ © USC-CSSE

9 University of Southern California Center for Systems and Software Engineering Application of the Sense, Compute, Control Style to Robots 09/28/ © USC-CSSE DaDA Central Component Sensor 1Sensor 2Sensor ‘N’ Actuator 1Actuator 2Actuator ‘M’ … …

10 University of Southern California Center for Systems and Software Engineering Application of the Sense, Compute, Control Style to Robots (cont.) A sensor is a physical, software-driven, device that identifies attributes of the system’s surroundings, e.g., nearby objects, nearby holes that can be fallen into by a robot, etc. The sensor sends information about these to the ‘Compute Component’ (but is rarely is sent messages by the latter component). An actuator/controller is a software-driven device that directly causes actions to be taken by physical components of the robot, e.g., to lift its arm a certain distance (It rarely sends messages to the Compute Component) The compute component receives information from the sensors, decides/computes what the various actuators should do next, and communicates that information to them. This ‘style’ imposes a natural limitation on ‘who can talk to whom’ and the ‘direction of communication’ 09/28/ © USC-CSSE

11 University of Southern California Center for Systems and Software Engineering Blackboard Style The example of the Star Topology architectural style whose component structure is shown on the next slide is called the Blackboard style. Very common types of systems for which the Blackboard style is appropriate are Artificial Intelligence systems systems like Yahoo Groups, Google Groups the Blackboard web learning system The Blackboard style may be appropriate for a few course projects that have been done over the past decade, but very few. 09/28/ © USC-CSSE

12 University of Southern California Center for Systems and Software Engineering DaDA Knowledge Repository Reader-poster 1 Blackboard Style (cont.) Reader-poster 2Reader-poster n … 09/28/ © USC-CSSE Topology: This style too follows a Star Topology

13 University of Southern California Center for Systems and Software Engineering Blackboard Style (cont.) To be specific in this style independent programs/entities access and communicate exclusively through a ‘global’ knowledge repository called the ‘blackboard’ Each reader-poster can, as the name suggests, post information to the Knowledge Repository and can read information posted by any reader-poster The Knowledge Repository may do no more than store posts, e.g., in applications like Yahoo groups, but may perform complex computations, e.g., in AI systems 09/28/ © USC-CSSE

14 University of Southern California Center for Systems and Software Engineering Blackboard Style – Qualities You don’t have to have complete solution strategies that are ‘preplanned’ or ‘predetermined’ The information in the knowledge base ‘evolves’ as the application progresses This evolving view of the problem (or data) determines the strategy(s) that are adopted for the solution Its typical application is in AI applications based on heuristic approaches to problem solving 09/28/2009© USC-CSSE Source: Software Architecture: Foundations, Theory & Practice – Richard N Taylor et al.

15 University of Southern California Center for Systems and Software Engineering Layered Style Most course projects are web services projects The architectural style that is most appropriate for the vast majority of web services projects is the layered style (i.e., multi-layered) The next slide shows a diagram of a three- tiered, also referred to as “3-layered”, architecture which is a special case of a multi- layer style 09/28/ © USC-CSSE

16 University of Southern California Center for Systems and Software Engineering 3-Tier Style View Layer Business Layer Data Layer 09/28/ © USC-CSSE Structural Visualization:

17 University of Southern California Center for Systems and Software Engineering 3-Tier Style (cont.) The View Layer is the component that implements the user interface, typically a graphical user interface (GUI) The Business Layer is the component that performs the computations that define the application The Data Layer is the component that holds data needed by the Business Layer to perform its computations Each of these layers discretely isolates the intended functionality for that layer 09/28/ © USC-CSSE

18 University of Southern California Center for Systems and Software Engineering Layered Style (cont.) In a multi-layer system each layer communicates with only the layer(s) adjacent to it, and performs that communication via a well-defined inter-layer interface, rather than, for example, directly calling for the execution of a method in the other layer Higher layers request ‘services’ from the lower layers – in a strict layered system, only the immediate lower layer would be called for its services The lower layer(s) respond to requests of the higher layers – again in a strict layered system the response is sent ONLY to the immediate higher layer 09/28/ © USC-CSSE

19 University of Southern California Center for Systems and Software Engineering Layered Style - Qualities Well defined structure with clear dependencies of each of the layers As long as the inter-layer interfaces remain unchanged, the implementation of the lower layers can be ‘changed’ without affecting the ‘services’ requested by the higher layer(s) Typical Applications: Protocol Stacks (e.g., TCP/IP) Operating Systems, Web Applications etc., 09/28/2009© USC-CSSE

20 University of Southern California Center for Systems and Software Engineering Architecture Building Blocks To set an initial vocabulary we define* the following elements that constitute the building blocks for an architectural description: –Components –Connectors –Configuration We explicitly define each of them in the subsequent slides. 09/28/2009© USC-CSSE *These definitions are those as stated in: Software Architecture: Foundations, Theory & Practice – Richard N Taylor et al.

21 University of Southern California Center for Systems and Software Engineering Choice of Software Architecture for 577 Projects The Layered Style is the most suitable one for the majority of from-scratch course projects The Layered style is often suitable for projects that use one or more NDI’s and one or more NCS’s, with each NCI and each NCS interaction embedded in the appropriate layer It is likely that most, if not all, teams working on projects other than COTS-assessment projects, should seriously consider using a multi-layer architecture, we will spend more time discussing it 09/28/ © USC-CSSE

22 University of Southern California Center for Systems and Software Engineering Why Software Architectures? The reason for dividing a system’s design/architecture into multiple layers, each of which requests something from the immediately lower layer through a well-defined interface, and which receives what it has requested through that well-defined interface has to do with testability, maintainability, and enhance-ability That is the greater the extent a component deals with once a single activity, i.e., the more cohesive it is, the more likely it is to be testable/debuggable, maintainable, and enhanceable The fewer direct data/control paths there are between components and between one component and the internals of another component: –the more debuggable, maintainable, and enhanceable that component is –the more likely the various components are to be integrable into a correctly working system 09/28/ © USC-CSSE

23 University of Southern California Center for Systems and Software Engineering Variations on the 3-Tier Style - I If the user interface of the system being defined is trivial (e.g., a single GUI page), then the small amount of view-layer code might just as well be incorporated into the Business layer, with no likely loss of the properties that motivate the 3-layer approach. The system’s architecture would then look as follows: Business Layer Data Layer 09/28/ © USC-CSSE

24 University of Southern California Center for Systems and Software Engineering Variations on the 3-Tier Style - II Similarly, if the business layer of the system being defined is trivial, e.g., a few trivial computations, then the small amount of Business-layer code might just as well be incorporated into the View layer, with no likely loss of the properties that motivate the 3-layer approach. The system’s architecture would then look as follows: View Layer Data Layer 09/28/ © USC-CSSE

25 University of Southern California Center for Systems and Software Engineering Variations on the 3-Tier Style - III … and so on and so forth Similarly, if the interactions with an NDI or an NCS are very complex, then the NDI, the NCS might well be dealt with as a component separate from one of the three typical layers, and may be assigned its own layer – or a part of one or more layers, e.g. View Layer Business Layer Data Layer NDI/NCS 09/28/ © USC-CSSE

26 University of Southern California Center for Systems and Software Engineering Event-Based Style Enforces certain constraints on the ‘communication’ of the various architectural elements Independent components communicate solely be sending events through something called as ‘event- buses’ The components send out events to the event bus which forwards it to all components (inefficient) or only to the ‘interested’/designated ones (more efficient) Thus ALL components can send/receive events – these events are usually asynchronous by nature 09/28/2009© USC-CSSE

27 University of Southern California Center for Systems and Software Engineering Event-Based Style Communication only via an event bus and NOT directly with each other 09/28/2009© USC-CSSE Event Bus (a.k.a Event ‘Router’) C1C2C3C-’N’ C1 is to be read as ‘Component 1’ and so on …

28 University of Southern California Center for Systems and Software Engineering Event-Based Style - Qualities Since this style consists of Independent components that asynchronously send/receive events over event- buses this style yields the following qualities: –Makes the system highly scalable and easy to evolve –Makes it most applicable for distributed and heterogeneous applications For 577: Most applicable for projects dealing with integrating various NDIs/NCSs – the emphasis is more on developing an effective event bus, so to speak. 09/28/2009© USC-CSSE

29 University of Southern California Center for Systems and Software Engineering Going ONE Level Deep So far we saw a relatively ‘high’ level view of the intended system structure To be able to reason about the system better, we go ‘one level deep’ and identify the various components and their interconnections, that will serve as a step towards analysis/design It MUST be possible to ‘map’ the components to ‘where’ they fit in the overall architecture (elaborated later) 09/28/2009© USC-CSSE

30 University of Southern California Center for Systems and Software Engineering Components Are architectural entities that: –Encapsulates a ‘subset’ of the system’s functionality and/or data –Restricts access to that subset via an ‘explicitly defined interface’ –Has explicitly defined ‘dependencies’ on its required execution context (i.e., required interfaces it depends on; resources such as files etc., on which it relies; required system software such as OS, device drivers etc.; and the hardware configurations that are needed) 09/28/2009© USC-CSSE

31 University of Southern California Center for Systems and Software Engineering Connectors - I An architectural element tasked with effecting and regulating interactions among components –Ex.: The ‘Event-Bus’ shown in the event driven style is actually a ‘connector’ that routes the events to the appropriate components that are ‘plugged in’ to the bus Usually receive second class status during analysis and are NOT made explicit – they are just shown as arrows/lines between components It’s a good practice to make them explicit during analysis 09/28/2009© USC-CSSE

32 University of Southern California Center for Systems and Software Engineering Connectors - II A few examples: –Procedure Calls: The most commonly known and used connector [No need to explicitly model it if it’s known/assumed] –Data Connectors: An example being ‘file’ based communication between components –Event Connectors: The aforementioned Event Bus A connector may be ‘composite’ i.e., a combination of various types 09/28/2009© USC-CSSE

33 University of Southern California Center for Systems and Software Engineering Architectural Configuration A set of specific associations between the components and connectors of a software system’s architecture An example configuration that shows both components and connectors along with their associations is shown below (Ci = Component ‘i‘, ‘Event Bus’ = connector, arrows = associations) 09/28/2009© USC-CSSE Event Bus (a.k.a Event ‘Router’) C1C2C3C-’N’ …

34 University of Southern California Center for Systems and Software Engineering Where do the Components Come from? The ‘Domain Model’ and the ‘Business Workflow(s)’ provide a very good starting point! Since the process of analysis/design is iterative in nature, the initial first cut identifications of these components is refined further as more is understood about the system These components could either be individual classes in the implementation or ‘groups’ of classes providing the functionality This is documented in the OCD under the section “Element-Relationship Diagram” – and ‘evolves’ over time! 09/28/2009© USC-CSSE

35 University of Southern California Center for Systems and Software Engineering A Practical Example In the previous lecture (on Domain Modeling) we presented a ‘rough’ Domain model for an internet bookstore. Since this is a ‘Web-based’ Application the 3- Tiered architectural style seems most applicable 09/28/2009© USC-CSSE Presentation Layer (Web Pages) Database Storage/Access Layer Application Logic/Business Rules Layer

36 University of Southern California Center for Systems and Software Engineering Component Identification A first-cut identification of components based on the ‘domain model’ and a set of ‘desired functionalities’ (or business workflows) is shown below: –Presentation Layer: a Login page, a Search page, a Results page, Shopping Cart edit/view page etc., –Application Logic: Components for Registration, Authentication, ‘Search’, User Account Management, Payment Calculation, Shipment Processing etc., –Data Layer: Components for accessing/storing Book Records; Book reviews/ratings; and user account information etc., i.e., information stored in a ‘database’ –NCS Layer: Interface to 3 rd Party Payment Services (Paypal etc.,) (at ‘same’ level as the Data Layer) 09/28/2009© USC-CSSE

37 University of Southern California Center for Systems and Software Engineering Possible Connectors The ‘Connectors’ for this application would be relatively high level at this stage: –HTTP requests/responses from ALL components in the View Layer to those in the Application Logic Layer –(Normal or Remote) Procedure calls from the Application Logic to the Data Access Layer (could also be event/file-based communication) –For simplicity let’s assume that the Data Access Components and the backend DB are “within” the same layer so the connectors can be simple procedure calls 09/28/2009© USC-CSSE

38 University of Southern California Center for Systems and Software Engineering Architectural Configuration – Internet Bookstore 09/28/2009© USC-CSSE Login PageSearch Page Shopping Cart Page Results Page HTTP Response/Reply Connector RegistrationAuthentication SearchShipment Processing Payment Calculation Store/Retrieve Book Records User Account Management Backend DB Payment Processing HTTP

39 University of Southern California Center for Systems and Software Engineering Element-Relationship Diagram The diagram on the previous slide IS an example of such a diagram The diagram shows the ‘relationships’ (associations) among the various elements of the system (i.e., an architectural configuration) The previous diagram can be ‘overlayed’ onto a layered architectural diagram to provide more structure/information as shown on the next slide 09/28/2009© USC-CSSE

40 University of Southern California Center for Systems and Software Engineering 09/28/2009© USC-CSSE Login PageSearch Page Shopping Cart Page Results Page HTTP Response/Reply Connector RegistrationAuthentication SearchShipment Processing Payment Calculation Store/Retrieve Book Records User Account Management Backend DB Payment Processing HTTP View Layer: Application Logic: Data Layer: NCS:

41 University of Southern California Center for Systems and Software Engineering Software Deployment For a software system to fulfill its intended purpose it MUST be deployed – i.e., the executable components are placed on ‘physical hosts’ on which they are intended to run It is a critical ‘perspective’ – can help ascertain the feasibility of implementation, runnability (i.e., if the platform can even support that many components or the communication bandwidth) 09/28/2009© USC-CSSE

42 University of Southern California Center for Systems and Software Engineering Deployment in 577 Projects Most 577 projects are deployed on what we call ‘Ubiquitous Hardware’ i.e., almost all machines are PCs/Macs running Windows, Linux or Mac OS and the like Rarely are 577 projects to be deployed on mobile phones or specialized devices like bar code readers etc. In some cases the deployment (and the corresponding diagram) are trivial i.e., the software system is installed only on one host 09/28/2009© USC-CSSE

43 University of Southern California Center for Systems and Software Engineering Deployment Diagrams UML provides what are called ‘Deployment Diagrams’ that show a deployment view of the software application These diagrams can either be –Technology independent (does not explicitly state the underlying platform on which it is being deployed) or –technology dependent (e.g., stating that the ‘View Layer’ will run on the ‘Client’s machine in some browser’ vs. stating it will run in Firefox/IE/Safari 09/28/2009© USC-CSSE

44 University of Southern California Center for Systems and Software Engineering Deployment Diagram – Internet Bookstore 09/28/2009© USC-CSSE :User Machine > (‘Displays’ View Layer Components) :Server Machine > (View Layer Components) :Server Machine > (Application + Data Layer Components) Internet Connection LAN Connection :Database Machine > (Backend DB) LAN Connection

45 University of Southern California Center for Systems and Software Engineering Deployment Diagrams (Cont’d) The previous slide showed a ‘first-cut’ view of what we think the deployment would look like Initially we have separated out the Web Server, Application Server and the Database (along with the corresponding components) on separate machines Further during the project we may realize that both the Web and Application Server run on the same machine and the DB on a separate one or all three run off the same machine As we learn more about the underlying platform, we change the diagram to reflect that (e.g., > instead of > or > instead of >) i.e., ‘platform specific’ diagram 09/28/2009© USC-CSSE

46 University of Southern California Center for Systems and Software Engineering Summary 1.Choose the most appropriate architecture style for the problem at hand based on the constraints/qualities desired 2.Provide an initial architectural configuration for analysis we produce a first-cut element-relationship diagram (AKA, component-connector diagram ) – taking inputs from the Domain Model, Business Workflows etc. 3.Provide a corresponding deployment perspective to analyze certain feasibility issues pertaining to the actual execution of the application 4.Except for step 2, everything else is documented in the respective section of the SSAD 09/28/2009© USC-CSSE


Download ppt "University of Southern California Center for Systems and Software Engineering CS577a: Elements of Software Architecture 09/28/2009 1 © USC-CSSE 2005-2009."

Similar presentations


Ads by Google