Sa 008 architecture_views


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The neurologist, the orthopedist, the hematologist, and the dermatologist all have a different view of the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems. The kinesiology's and psychiatrist are concerned with different aspects of the entire arrangement's behavior. Although these views are pictured differently and have very different properties, all are inherently related: Together they describe the architecture of the human body.So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all at once. Instead, we 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-which view we are taking of the architecture.We will be using the related terms structure and view when discussing architecture representation. A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. It consists of a representation of a set of elements and the relations among them. A structure is the set of elements itself, as they exist in software or hardware. For example, a module structure is the set of the system's modules and their organization. A module view is the representation of that structure, as documented by and used by some system stakeholders. These terms are often used interchangeably, but we will adhere to these definitions.Architectural structures can by and large be divided into three groups, depending on the broad nature of the elements they show. Module structures. Here the elements are modules, which are units of implementation. Modules represent a code-based way of considering the system. They are assigned areas of functional responsibility. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as 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? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships? Component-and-connector structures. Here the elements are runtime components (which are the principal units of computation) and connectors (which are the communication vehicles among components). Component-and-connector structures help answer questions such as 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? How does data progress through the system? What parts of the system can run in parallel? How can the system's structure change as it executes? Allocation structures . Allocation structures show the relationship between the software elements and the elements in one or more external environments in which the software is created and executed. They answer questions such as 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? These three structures correspond to the three broad types of decision that architectural design involves: How is the system to be structured as a set of code units (modules)?How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)? How is the system to relate to non software structures in its environment (i.e., CPUs, file systems, networks, development teams, etc.)?
  • Component diagrams are particularly useful with larger teams.  Your initial architectural modeling efforts during cycle 0 should focus on identifying the initial architectural landscape for your system.  UML component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components.  Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between sub teams. You will discover the need to evolve the interfaces to reflect new requirements or changes to your design as your project progresses, changes that need to be negotiated between the sub teams and then implemented appropriately.
  • A component is a principal unit of runtime interaction or data storage; a connector is an interaction mechanism among components. For example, in a pipe-and-filter view, filters are components, and pipes are the connectors. In a shared-data view, the data repository and the accessory are the components, and the access mechanisms are the connectors. In a client-server view, the components are clients and servers, and the connectors are the protocol mechanisms by which they interact.
  • Deployment diagrams are mostly (and almost exclusively) used for distributed applications. These diagrams show on which machines which parts of the software is running (a physical mapping of software to hardware infrastructure). Also communication links between different computers are indicated. A deployment diagram node can represent any computational unit, i.e. any device having some information processing capability, ranging from a simple temperature sensor to a regular computer.
  • The user interface (UI) manager handles the look-and-feel of the client's user interface. However, given the open-ended set of resources that a WWW system can handle, another element, the presentation manager, can delegate information display to external programs (viewers) to view resources known by the system but that the UI manager does not directly support. For example, most Web viewers use an external program to view PostScript or .pdf files. This delegation is a compromise between the competing desires of user interface integration (which provides for a consistent look-and-feel and hence better usability) and extensibility. The UI manager captures a user's request for information retrieval in the form of a URL and passes the information to the access manager. The access manager determines if the requested URL exists in cache and also interprets history-based navigation (e.g., "back"). If the file is cached, it is retrieved from the cache manager and passed to the presentation manager for display to either the UI or an external viewer. If it is not cached, the protocol manager determines the type of request and invokes the appropriate protocol suite to service it. The client stream manager uses this protocol for communicating the request to the server. Once it receives a response from the server in the form of a document, this information is passed to the presentation manager for appropriate display. The presentation manager consults a static view control configuration file (mimerc, mailcap, etc.) to help it map document types to external viewers. The HTTP server ensures transparent access to the file system-the source of the documents that the Web exists to transfer. It does this either by handling the access directly (for known resource types) or through a proxy known as common gateway interface (CGI). CGI handles resource types that a native server cannot handle and handles extension of server functionality, as will be discussed next. Before these extensions, the available WWW servers implemented a subset of defined HTTP requests, which allowed for the retrieval of documents, the retrieval of document meta-information, and server-side program execution via CGI. When a request is received by the server stream manager, its type is determined and the path of the URL is resolved via the path resolver. The HTTP server consults an access list to determine if the requesting client is authorized for access. It might initiate a password authentication session with the client to permit access to secured data. Assuming authentication, it accesses the file system (which is outside the server boundary) and writes the requested information to the output stream. If a program is to be executed, a process is made available (either new or polled) through CGI and the program is executed, with the output written by the server stream manager back to the client. In either case, CGI is one of the primary means by which servers provide extensibility, which is one of the most important requirements driving the evolution of Web software. CGI became such an important aspect of Web-based applications that we now discuss this topic at greater length.
  • Sa 008 architecture_views

    1. 1. Software Architecture F. GielenArchitectural Views Vakgroep Informatietechnologie – IBCN
    2. 2. Software Architecture Definition The Software Architecture of a program or computing system is the structure or structures of the system, which comprises software elements, the external visible properties of those elements and the relationships among them.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
    3. 3. Where do views come from ? A software architecture is multi-dimensional & complex entity that cannot be described in a simple one- dimensional fashion. To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment - which view we are taking of the architecture. Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
    4. 4. Architectural views – Ph.Kruchten A view is a set of coherent architectural elements. Programmers - Software managementEnd user - Functionality - Vocabulary Design Component view view Use case Analysts/Testers - Behavior view Process Deployment view viewSystem integrators System engineering- Performance - System topology- Scalability - Delivery and installation- Throughput - CommunicationVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
    5. 5. Architecture Documentation Challenges How do you decide which architectural views to document? What information do you record about an architectural view beyond the box-and-line diagram? How do you specify an architectural elements software interface? What information do you record? How do you specify an elements behavior? What notations are available for documenting a view, an interface or behavior?Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
    6. 6. Architecture Description Languages Requirements UML Software ArchitectureAn ADL is a language that provides features for modelling a softwaresystem’s conceptual architecture.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
    7. 7. Architecture Structures STATIC view : What is the structure of the system ?  What is the primary functional responsibility assigned to each structure?  What other software elements is a module allowed to use?  What other software does it actually use? DYNAMIC view: What is the runtime behavior of the system ?  What are the major components ? How do they interact , communicate ?  What are the major shared data stores? Which parts of the system are replicated? How does data flow or progress through the system?  What are the system states ?  What parts of the system can run in parallel and are concurrent ? DEPLOYMENT view : Allocation Structures.  Relation with external elements  What processor does each software element execute on?  In what files is each element stored during development, testing, and system building? Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
    8. 8. UML 2.0 for ArchitectureVakgroep Informatietechnologie – Onderzoeksgroep IBCN 8
    9. 9. STATIC Views & Modules Structures Module Decomposition Class Uses LayeredModules are units of implementation.  with functional responsibility  is a sub module of and uses - relations  generalisation -> re-use & incremental development  associated products: test plan, interface specification, code …etc.Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
    10. 10. Module Structures in UML Represented stereotyped packages, classes and interfaces Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
    11. 11. UML Interfaces Representations Provided interfaces Required interfaces Example: HTTP Server Vakgroep Informatietechnologie – Onderzoeksgroep IBCN 11
    12. 12. Component Diagrams A component is a modular, autonomous unit with well defined interfaces. They are particularly well suited for initial architectural modeling. Static View Dynamic View Vakgroep Informatietechnologie – Onderzoeksgroep IBCN 12
    13. 13. DYNAMIC Views & Component-Connector Component – Connector Structures Communication Shared data Processes Concurrency Client - ServerComponents are runtime units  computational units  parallelism, identify resource contentionConnectors are interaction mechanism amongcomponents  communication & synchronisation mechanism  interaction, data flow (persistence).Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
    14. 14. Dynamic Views in UMLVakgroep Informatietechnologie – Onderzoeksgroep IBCN 14
    15. 15. Interaction diagramsInteraction diagrams show the communication behaviorbetween parts of the systemFour types of Interaction diagrams  Sequence diagram  Emphasis on the sequence of communications between parts  Communication diagram  Emphasis on structure and the communication paths between parts  Timing diagram  Emphasis on change in state over time  Interaction overview diagram  Emphasis on flow of control between interactions Vakgroep Informatietechnologie – Onderzoeksgroep IBCN 15
    16. 16. Sequence diagramVakgroep Informatietechnologie – Onderzoeksgroep IBCN 16
    17. 17. Communication DiagramVakgroep Informatietechnologie – Onderzoeksgroep IBCN 17
    18. 18. Example: Static & Dynamic viewVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18
    19. 19. DEPLOYMENT Views & Allocation structures Allocation Work Deployment Assignment ImplementationAllocation structures show relations in theexternal environment:  assignment to processors and communication resources  mapping to file structures and build systems  who does the workVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
    20. 20. UML Deployment Diagrams aN ode Node ≈ “computational unit” (processor, computer, sensor, ...)Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20
    21. 21. Example WWW Client ServerVakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21
    22. 22. HTTP Client Module UI manager : Responsible for the look and feel of the UI (e.g., web browser) Presentation manager Delegates document types to viewers  external: QuickTime movies, MP3 audio, etc.  internal: HTML, GIFs to UI manager Scenario: UI manager captures user’s requests for URL and passes to Access manager Access manager determines if URL has been cached; if not, it initiates retrieval through Protocol and Stream managers Response stream sent to presentation manager for appropriate display Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
    23. 23. HTTP Server Module Hypertext Transfer Protocol (HTTP) server : Receives URL request and passes that the Path resolver, which determines the file location for the document (assuming local) Checks the access list to see if access is permitted (may initiate password authentication session) and then gets the document from the file system and writes it to the output stream Common Gateway Interface (CGI) Special document type that allows customized access to other data or programs Also writes to output stream HTML stream is sent to the client by the HTTP server Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
    24. 24. Common Gateway Interface (CGI) HTTP server : transparent access to the file system by:  Handling access directly for known types  Passing unknown types to a “proxy” server known as Common Gateway Interface (CGI) CGI  Most information returned by the server is “static”  CGI provides for the dynamic generation of responses e.g. “looking something up in a database”  Virtual documents or dynamic documents  CGI Scripts: C, C++, Perl, Visual Basic, AppleScript, PHP, Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24