Implementation Architecture PDF

Implementation Architecture Software Design and Architecture Outline Definition Design Behaviour Requirements Prototypes  Definition What is implementation architecture? Implementation Architecture Focuses on how the system is built Which technological elements are...

Implementation Architecture Software Design and Architecture Outline Definition Design Behaviour Requirements Prototypes  Definition What is implementation architecture? Implementation Architecture Focuses on how the system is built Which technological elements are needed to implement the system Software packages, libraries, frameworks, classes,... Addresses non-runtime requirements & quality attributes: configurability, testability, reusability,... Comprised of components and connectors Implementation Architecture Components and connectors reflect software entities and their relationships at the level of source and binary code Typically a number of implementation models Each model focuses on one of the concurrent subsystems or processes from the execution view Components Two types of components: Application Infrastructure Components Application components... are responsible for implementing domain-level responsibilities These are responsibilities found in a detailed conceptual architecture Application components might be realized as binary packages, source packages, and files Components Infrastructure components... are needed to make the system run but are not related to the application functionality E.g. HTTP Connection Handler in our sample is a typical infrastructure component Whether a particular component is an application or an infrastructure component depends on the application E.g. if we are building a Web application server then HTTP Connection Handler is an application component Components Often an infrastructure component acts as a “container” for application components A container component provides an execution environment for the contained components and manages their lifetime Typically, the container executes within a process and creates threads for application components E.g. a Web application server which runs multiple applications, each of them in their own threads Component stereotypes Figure: Implementation stereotypes from Software Architecture Primer Connectors In implementation architecture connectors represent a “uses” relation The arrow depicts the direction of this relation The nature of communication is depicted through the connector styles Connectors API call: A component calls a method in another component (possibly only if both components are in the same process) Callback: The caller passes a reference of an object to the callee. The callee invokes a method on that object later. Network protocol: Needed when implementation components reside in different processes on networked machines. Components need to agree on a common protocol or use a standardized protocol OS signals: Communication between processes running on the same machine Connectors Figure: Implementation connectors from Software Architecture Primer Connectors In some cases we depict ports as endpoints of connectors between components and their interfaces Ports are used to represent the communication between inside and outside of a component Interfaces are the specification how the communication looks like, e.g. the API E.g. a component might be quite complex but it provides a simple interface for communication Interfaces Interfaces are part of the implementation architecture Usually depicted via the lollipop notation, while ports are depicted as little squares They expose the responsibilities Typically interfaces change more slowly the components Interfaces abstract out hardware... they can be standardised Interfaces allow distribution Ports and interfaces are optional and should be used only if they are relevant for the model Example Figure: Example of implementation architecture from Software Architecture Primer Conceptual vs. Implementation Element Conceptual Implementation Components Domain-level responsibilities Implementation module Connectors Information flow “Uses” relationship Views Single Split Conceptual vs. Execution vs. Implementation Figure: Conceptual vs. execution vs. implementation from Software Architecture Primer  Design How to design the implementation architecture Implementation architecture design 1 Define application components 2 Define infrastructure components 3 Define interfaces 4 Behaviour design and verification Application components Ideal 1-to-1 mapping of conceptual components onto application components is typically not possible Some conceptual components will become infrastructure components E.g. persistent storage (databases) are typically infrastructure components Some conceptual components are spread over a number of application components... if conceptual components have complex responsibilities Application components A number of conceptual components can be mapped onto a single application component... if few and simple responsibilities Complex conceptual components might map on additional application components UI components map onto one application component (i.e. HTML UI) Infrastructure components Off-the-shelf components Frameworks (e.g. application framework) Servers (web, application, database, file) Generic clients (browser) Sample infrastructure components Consider a simple Web application (e.g. the navigation application): There are least two infrastructure components: browser, application server Web browser Web application server Apache Tomcat: http://tomcat.apache.org/ Reference implementation of the Servlet API Servlet API abstracts the HTTP protocol from programmers and allows to write Java classes that handle HTTP requests Sample infrastructure components public class SomeServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {... PrintWriter out = response.getWriter();... } } Sample infrastructure components With a servlet we can read parameters from the user E.g. dataset name, dataset file We can respond with HTML E.g a new input form for selecting the start and end point for the route Sample infrastructure components Servlets are still very low level We want to operate on a higher level of abstraction than reading/handling user parameters There are frameworks which abstract e.g. HTTP request/response cycle For example, for general UI applications MVC frameworks Component-based frameworks such as Google Web Toolkit Also, Java servlets are just one possibility (Python, PHP, etc..) Infrastructure selection Research on which infrastructure to choose (or to develop) Conceptual issues, e.g. MVC, component-based, service-based,... Execution issues, e.g. spawning of external processes Implementation issues, e.g. programming language Contextual issues, e.g. commercial products, open source, etc. Organizational issues, e.g. know-how, team,... Infrastructure selection Trough research you will obtain a list of several infrastructures Identification of criteria set (what is important) Weighting of criteria (to what extent is some feature important) Evaluation of modules Selection (of the best infrastructure) Weighted Scoring Method There are n alternatives A1, A2,..., An There are m different criteria C1, C2,..., Cm Each alternative is for each criterion with score Sij Each criterion has a weight relative to its importance W1, W2,..., Wm The final score for the alternative Ai: ∑m S(Ai) = SijW j (1) j= 1 Weighted Scoring Method For uniform distribution of weights: m 1∑ S(Ai) = Sij (2) m j=1 Weighted Scoring Method - Example Weighted Scoring Method - Example Sample infrastructure selection Apply the same methodology for your projects We select Open Source Java with Tomcat We select component-based framework Apache Wicket as a Web application framework We select Postgres as database backend We selected to develop the navigation algorithm my ourselves Interface design For all application and infrastructure components we need to define interfaces (ports) Helps in clarifying the responsibilities of a component Some interfaces are also standardized E.g. HTTP, SQL, File I/O Sample interface design UI: Combination of HTML/HTTP It is standardized! Web application server: HTTP/Servlet API It is standardized Component separation Wicket components are specified by the framework Sample interface design We need to specify interface between Wicket and our application logic A new interface is needed We need to tell to the application logic that there is a request for an e.g. calculation e.g. findOptimalRoute(user, places, criteria) Sample interface design We should also tell to the system where to write routes, datasets, users, etc. Typically these are only files We can store users in an e.g. XML file e.g. users.storeUser(user);  Behaviour Dynamic aspects of implementation architecture? Behavior design Now we need to go into details Use-case maps are too high level here We need to investigate behaviour at the operation level Thus, we need for example sequence diagrams Still, use-case maps might be used to analyse e.g. runtime attributes Sample implementation Architecture Figure: Detailed sample implementation architecture Sample implementation Architecture Figure: Alternative implementation architecture Sample interface Sequence Diagram Figure: Sample sequence diagram Practical Guidelines Mapping of conceptual components to implementation components One-to-one ▶ Implementation component supports all responsibilities ▶ Without breaking principles of granularity, cohesion and coupling One-to-many ▶ Responsibilities cannot be mapped onto a single implementation component ▶ Specific architectural style requires multiple components Many-to-one ▶ Existing product that encapsulates the functionality of multiple conceptual components ▶ Maintainance might be simpler for a single component ▶ Specific architectural style requires a single component  Requirements What kind of requirements are addressed? Non-runtime requirements Since implementation view addresses build structure It is the right place to consider non-runtime requirements & quality attributes E.g. maintainability, extensibility, reusability,... We can use a mechanism similar to use-case maps Impact-maps: try to investigate what parts of the system need to change if “something” happens Fault tree analysis: how does a failure cascade throughout the system Tools to identify and explore architectural issues Impact-maps Map 1: new external system - interface to external system needs to be changed Map 2: new optimal criterion - route finder application component needs to be changed Map 3: new UI - UI component needs to be changed Goal: as few component changes as possible  Prototypes About time to build the system Prototype To show that the architectural solution is feasible we implement prototypes For each identified application component we provide implementation Deploy it within the infrastructure components Test it and check correctness, functionality, quality-attributes Two types of prototypes: technical and executable Technical Prototypes Technical prototypes are used assess feasibility of an architecture... or to discover and quantify parameters Quickly developed to serve their purpose, but not at product quality level This kind of prototype should be thrown away (should not make it into the final product) Test out new technologies and components (or new versions) e.g. is a certain database suitable? does are certain framework scale to our expected number of users?... and also to test whether the skill of the team is suitable Mock-Ups Mock-ups are special technical prototypes, especially for user interfaces Serve as the communication tool with the stakeholders (and within the team) Should give an overview on how the system will look like But does not contain any functionality There are specialised tools to create mock-ups Executable Prototypes Executable prototypes are a skeleton of the system itself First development cycles in an iterative process, evolutionary prototyping... thus the code is not thrown away and code (and documentation) need to be at product quality level Includes all components of the system (infrastructure, UI,...), but only fragments of the functionality The remaining functionality is then added iteratively Discover flaws in the architecture early on Assess the performance of the overall system Blends well with agile development processes, e.g. Rapid Development [McConnel 1996], Unified Process Within in evolutionary prototyping, technical prototypes might be develped → be precise, which type of prototype is being developed Big Blue Button Architecture Discussion https://docs.bigbluebutton.org/development/architec ture