2 Implementation View (1) Focuses on “how the system is built”Which technological elements are needed to implement the system:Software packages (req. Development tools),Libraries (implementing behavior e.g. “Cout”),Frameworks (Generic functionality e.g. “JUnit”),Classes , ...Addresses non-runtime quality attributes:Configurability (e.g. Platform),Testability (e.g. Mapping of FRs),Reusability
3 Implementation View (2) Again, comprised of components and connectorsHere, components and connectors reflect“Software entities and their relationships at the level of source and binary code”Typically a number of implementation models can be developedEach model focuses on the concurrent subsystems/processes from the execution view.
4 A view focussing on… Build-time structure: Detailed activity As, implementation architecture focuses on the “built-time” structure of the system.Build-time structure:Implementation modulesOff-the-shelf technologyBuild-time configurationDetailed activityCall sequences i.e. Sequence Diagram
5 Components in implementation architecture (1) Two types of components:Application componentsAnd infrastructure components
6 Components in implementation architecture (2) Application components:“Are responsible for implementing domain-level responsibilities”These are responsibilities found in a detailed conceptual architectureApplication components might be realized as:Source packages,And files
7 Components in implementation architecture (3) Infrastructure components:“Are needed to make the system run but are not related to the application functionality”e.g. LAN Connection Handler in Distributive system is a typical infrastructure component(Just use to connect local systems, so they can communicate when they require)
8 Components in implementation architecture (4) Often an infrastructure component acts as a "container" for application componentsA container component provides an execution environment for the contained components (application components)Typically, the container executes within a process and creates threads for application componentse.g. a Web application server which runs multiple applications from multiple users, each of them in their own threads.
9 Component stereotypes in implementation view InfrastructurecomponentContainersApplicationcomponents
10 Connectors in implementation architecture (1) In implementation architecture connectors represent:“a "uses" relation”The arrow depicts the direction of this relationThe nature of communication is depicted through the connector styles
11 Connectors in implementation architecture (2) 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” (called component). The “callee” invokes a method (desired computation) on that object later and return the results to caller.
12 Connectors in implementation architecture (3) Network protocol:Needed when implementation components reside in different physical layer. Components need to agree on a common protocol or use a standardized protocolOS signals:Communication between processes running on the same machine
14 Connectors in implementation architecture (5) In some cases, we represent ports as:“endpoints of connectors between components”Ports are used to identify a particular interfaceFor example:A component might be quite complex but it provides a simple interface for communicatione.g. the standard Java library provides an API (Application Programming Interface).
15 Simple “two-tier” web app InfrastructurecomponentApacheApache module APIPortsHTTPmod_phpContainersApplicationcomponentsMySQLDataModel/s
16 Conceptual v/s implementation ArchitectureImplementationArchitectureDomain-level responsibilitiesImplementation moduleComponentFlow of information“Uses” relationshipConnector
18 Application components (1) 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 componentsSome conceptual components are spread over a number of application componentsConceptual components have complex responsibilities e.g. Application layer (Request acceptor , Request Handler e.t.c)
19 Application components (2) A number of conceptual components can be mapped onto a single application componentE.g. small number and simple responsibilitiesMPS system is such an example:All UI components map onto one application component(i.e. HTML UI)
20 Infrastructure components Off-the-shelf components (e.g. Third party services)Frameworks (e.g. application framework)Servers (web, application, database, file)Generic clients (browser)In MPS system two infrastructure components:Browser,Application server
21 Interface designFor all application and infrastructure components we need to define “interfaces” (ports)Helps in clarifying the “way to connect” the componentsSome interfaces are also standardizede.g. HTTP Connectivity, SQL ConnectivityUI: Combination of HTML/HTTPIt is standardized!
22 Behavior design Now we need to go into details Use-case maps are not enough anymoreWe need to investigate behavior at the operation levelThus, we need a sequence diagram
24 Non-runtime quality attributes Since implementation view addresses build structureIt is the right place to consider non-runtime quality attributes, e.g.Maintainability,Extensibility,Reusability, ...We can use a mechanism similar to use-case mapsImpact-maps:“try to investigate what parts of the system need to change if "something" happens”
25 Impact-maps Map 1: new external system Map 2: new application interface to external system needs to be changedMap 2: new applicationapplication component needs to be changedMap 3: new UIUI component needs to be changed
26 Implementation arch. summary What you need to submit at end of Implementation Architecture:Detailed implementation architecture with app, infrastructure and interfacesSequence diagram of application interfaces
27 PrototypeTo show that the architectural solution is feasible, we implement prototypes:For each identified application component we provide implementationDeploy it within the infrastructure componentsTest it and check:Correctness,Functionality,Quality-attributes
28 Dimensions of prototypes (1) Horizontal Prototype:A common term for a “user interface” prototype is the horizontal prototype.It provides a broad view of an entire system or subsystem, focusing on user interaction more than low-level system functionality,such as database access.Horizontal prototypes are useful for:Confirmation of user interface requirements and system scopeDevelop preliminary estimates of development time, cost and effort.
29 Dimensions of prototypes (2) Vertical Prototype:“A vertical prototype is a more complete elaboration of a single subsystem or function”It is useful for obtaining detailed requirements for a given function, with the following benefits:Refinement database designClarifies complex requirements by drilling down to actual system functionality
30 Technical prototypes (1) Throwaway or Rapid Prototyping refers to:“creation of a model that will eventually be discarded rather than becoming part of the final delivered software”A simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.Also called close-ended prototyping.
31 Technical prototypes (2) A “throw-away”The prototype code is not part of the delivered systemNo concern for irrelevant quality attributes (performance, robustness)Purely to gain knowledge (or confidence):Test a new version of a commercial componentVerify that a set of components work togetherExamine performance trade-offsVerify that a proposed architecture is sound
32 Technical prototypes (3) Evolutionary Prototyping:“the main goal is to build a very healthy prototype in a planned manner and constantly refine it.”The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built.When developing a system using Evolutionary Prototyping, the system is continually refined and rebuilt.
33 Technical prototypes (4) This technique allows the development team to:Add features,Or make changesEvolutionary Prototypes have an advantage that they are functional systems.They may be used on temporary basis until the final system is delivered.