Designing Software Architecture • All human can design ! – Do you believe in this? (matter of degree?) • Design, as a set of activities, may be analyzed ! – Do you believe in this? (partially or totally?) We are even trying to “teach” this subject here! Architecture Design Stages The Design Process may be summed into 4 “stages”: 1. feasibility : identifying potential design concepts 2. preliminary design: selecting and developing the “best” design concept 3. detail design: further defining and refining the design concept 4. planning: evaluating and altering (or tuning) the design concept to fit the requirements of software development, production, consumption, and retirement Just like everything we do, this is not clear-cut and all sequential. Some Concerns over the Design “Process” • Start-up problem: Identifying potential design concepts (the first step is very important & may be the key stumbling block). • People problem: For a very large software system, there may be a need for more than one architect or chief designer ---increasing the chance of not agreeing on any design concept. • Complexity problem: for a system that is composed of many heterogeneous components or parts, the complexity of finding an overall system becomes very large and sometimes prohibitive. In the case of internet architecture (e.g. SOA), it becomes extremely difficult Design Activities are Not Straightforward Increases in difficulty • One may wonder around a while in the beginning to get started: 1. 2. 3. 4. • Looking and understanding at key requirements mapping functional requirements to major components relating the components to produce the overall system Analyze the relationships in terms of non-functional required properties (e.g. performance, security, reliability, etc.) As we proceed, we will revisit, refine, and modify the original ideas. Design activities are not always performed sequentially: – – – – In cyclical mode In parallel mode In incremental mode In adaptive mode Any Help? • Some “Basic” Design Approach/Tool: – Abstraction – Separation of Concern – Decomposition/Composition (my words) • These concepts are not totally separate ABSTRACTION • Abstraction may be defined in many ways: – “The selection of a set of basic concepts to represent a more complex whole” --- from your text – The simplification and ignoring of the details to emphasize what is considered as important. “SHAPES” – The generalization from the details and the specifics Do you remember how many dogs and cats you saw as a child before you realized the “class”-dog and the “class”-cats ?! ---- follow the 1-2 year olds sometime and see how they cope with the problem of “classification”. A B S T R A C T I O N More on Abstraction • We often start by “matching” a problem component to some abstract model/solution: – Major requirement (problem domain) – Major solution (modeling “abstraction” or “machine”) Application Problem domain Simple Abstract “machine” word processing document & layout process control finite state machine financial & accounting spreadsheet & database scientific computing web pages matrices and algorithms HTML based document etc. etc. Levels of Abstraction Decomposition & Composition SHAPES Red arrow = decomposition Blue arrow = composition “2-D” shapes Ovals Triangles Arrows Approaches to Levels of Abstraction • Work at a level below the “whole” component or application. • we are looking at solutions to sub-components and then compose & generalize the solutions to apply to the whole • work at a level above the “whole” or desired application • we are looking at a more general solution and applying only the specific parts of the general solution to the problem at hand and fine tune to specialize the solution . Try during the class • How would you approach “abstracting” the description & design of a system for the following? – – – – – – – On-line classes In-class lectures Part-time students Adult-students Full-time students Full time lecturers Part-time lecturers Separation of Concern • Separation of Concern is the subdivision or decomposing of a problem into “independent” parts. – Functional components and sub-components – Connectors that “interconnect” components • Most of the time total independence is not possible, but we want: – Each individual component to have strong cohesion – The components to have loose coupling Recall that cohesion and coupling are important software properties. Any Other Help in Designing Architecture? • Just as in other fields, past experiences provide fertile ground for potential solutions: – to satisfy a specific goal – within some particular application context (context Ξ constraints?) • In software architecture we may also use these past experiences, expressed in the form of architectural “styles” and “patterns” A Broad View of Styles & Patterns deep some combine these into “styles” Architectural patterns Domain Specific Software Architecture Design Styles App Domain Knowledge Design patterns we focus on these 3 mostly for OO detail design & programming shallow programming level software design component level Scope Applicability Software System level Domain Specific Software Architecture (DSSA) • Domain Specific Software Architecture contains a substantial amount of information based on past experiences within the specific application domain: 1. 2. 3. a reference architecture for a specific domain, a library of software components containing reusable chunks of domain expertise, and a method of choosing and configuring components to work within an instance of the reference architecture. (1) reference architecture for domain x (2) domain components Domain core (3) “Core must be a part of every instance and -------” Architectural Patterns • Architectural Pattern: a named collection of architectural design decisions that are applicable to a recurring design problem, parameterized to account for different software development contexts in which the problem occurs. • Fundamental sets of architectural patterns: – State-Logic-Display (3-tier architecture) – Model-View-Controller (web application) – Sense-Compute-Control (sensor-control-actuator / real time) State-Logic-Display (3-tier) • State-Logic-Display is the familiar architecture pattern where – users access business functionalities through a user “display.” – the business functionalities are provided through the “logic” part, – and the data store keeps all the persistent data or “states,” usually in a database • In some ways this is the precursor of the now popular M-V-C architecture discussed next. request User Interface (Display) response Business Logic (Logic) request response Database (State) the software components may be distributed across hardware Model-View-Controller (MVC) • Model-View-Controller is an architectural pattern which resembles the 3 tier, but focuses more on the “management of User Interaction.” It contains: – Model which manage the storage of the data – View which accepts and displays information to the user – Controller which aid in the control and modification of the way information is managed between the view and the model. (Sometimes, especially in web applications, the business logic is placed in Controller) View Model Controller Today’s Popular Model with JSP for dynamic presentation content 1 Browser JSP 4 2 Java Bean 3 Data Base/ enterprise system (Simple model - more complex JSP) 1 Servlet (controller) 3 Browser 6 JSP (view) 2 4 Java Bean 5 (model) Data Base/ enterprise system (Model-View-Controller (MVC) model - separate controller from view) Sense-Compute-Control (Real-time) • Sense-Compute-Control is an architecture which is composed of: – Sensors which sends information from various sources – Compute component which receives the information from sensors and performs all the necessary numerical and logical computations and the sends the result as signals to the Control – Control which receives the results of the computation from the compute component and decides how to control the various devices. • This is an architectural pattern often used in embedded systems. control B sensor 1 control C sensor 2 sensor 3 Compute control D control A Even though arrows go from sensors to compute, it could be compute polling the sensors. Architectural Styles • Architectural styles covers the “broadest” lessons and experiences that are used in software design. It reflects less domain Recall, design decisions address: knowledge and is higher than programming constructs. It is a named1. elements and their arrangements 2. behavior of elements collection of design decisions that: 3. interactions of elements 4. non-functional properties 5. implementation guidelines – is applicable in a specific development (& problem/solution) context – constrains architectural design decisions to a particular system within that context – elicits beneficial qualities in the resulting system An Architectural Style descriptively defines a particular codification of design elements and formal arrangements. It prescriptively constrains the kinds of design elements and their arrangements. (It defines and limits the structure --- my words) Classifying Architectural Styles • Simple – – – – – – – Traditional programming language influenced style Layered Dataflow Shared Memory (Shared State) Interpreter Implicit Invocation Peer-Peer • More Complex – C2 (component & connectors) – Distributed Object Traditional Language-Influenced Style • This is based on a “main component” that calls upon functional “sub-components” – Traditional programming paradigm • Software decomposed into 1) main program and 2) subroutines • The main program calls the subroutine which in turn may call other subroutines • This paradigm gave us the traditional hierarchical style of main and (decomposed) subcomponents – OO programming paradigm • Software decomposed into objects, one of which may be assumed to play the “main” program role • The methods in the objects are invoked much like a procedure call. • The objects are meant to represent the entities in the requirements/application world. Layered Style • Software is decomposed into layers where: – Each layer may request the service of the layer (usually immediately) below it – Each layer provides the service for the layer immediately above it. Layer 1 Layer 2 Layer 3 Prog. A Prog. B Prog. C Prog. D any advantage or disadvantage ? ---- think of performacne, error location, secuioryt, etc. Operating System Example of Layered Style Applications Programs print “ Hi” Operating System Services process scheduler Hardware Interrupts & Kernel HP ServicesDevice printer service I/O Cross layer Within layer Dataflow Style • Separate, independent components or programs are executed in some sequential order as data is passed through them to be processed – Batch sequential processing – Pipe and Filter (data flows through pipe to be processed by filter) regional daily transactions regional daily transactions sort/merge by accnt. # sorted daily transactions update Master file Master File regional daily transactions these “transactions” may be credit cards, stocks, etc. --- advantage/disadvantage? Shared-State or Shared-Data Style • Independent components or programs interact through shared “global” data – Blackboard – Rule based system • This style is used in many commercial systems that has a “centralized” database Strongly Data Coupled ! a) Risks? b) Advantages? Component A Component B Component D Shared Repository Component C Component E Interpreter Style • This is a parse, (generate code), and execute each command; maintain the state of the execution. – Basic interpreter : Basic or Java interpreter; Excel code and graphs – Mobile code : transmitting code to remote locations for execution • Code on demand (have the data but downloads the code to execute ---- image processing with Adobe photo-shop.) • Remote evaluation (information is sent to remote site to be processed and results are returned --- such as in “grid” computing) • Mobile agent (information, code, and any required resources are moved to another site and the results may not be returned Implicit Invocation Style • Components are invoked indirectly and implicitly as a response to some event or notification (similar to the sense-compute-control pattern discussed earlier) – Publish-Subscribe • There is a producer and consumer of information • Popular with internet “special news” such as “paid” financial information by industry sector for investors who subscribe to it. – Event-Based (a general case of Publish-Subscribe) • independent components communicate solely via sending “events” via a event-bus connector with no designated publisher or subscriber. • Information (events) distribution may be processed via – Push or – Pull Peer-Peer Style • A network of “loosely-coupled” autonomous components, each may act as a server and a client. – This ideal situation is usually modified with some amount of centralized control or a directory. • Originally used for sharing files (e.g. Napster music files) • Instant message or chat is closest to p2p style. More Complex Styles • While we do not have any formal “rules;” but previous styles may be composed, extended, and modified to develop more complex styles as needed. Two such styles catered to i) distributed and ii) heterogeneous components are: – C2 (component and connectors) Style – Distributed Object Style C2 (Components and Connectors) Style • This styles allows various components to be developed independently, but still communicate, interact and produce the desired results with the help of “connectors” and has following set of rules: – – – – Topological connection rules Message based communication rules Message flow and Substrate Independence rules Interfaces rules Component A Component A Connector 1 Connector 2 Component B Component C C2 Rules in detail – Topology Rules: • each component and each connector has a defined top and bottom. • A component may be attached to only one connector (up/down). • Arbitrary number of components and connectors may be attached to a connector • The top of a component may be attached to the bottom of a connector; the bottom of a component may be attached to the top of a connector. Same rules applies to attaching two connectors – Message Based Communication Rules: • All communications between components are via “messages” • A message is classified as i) request for performing a service or ii) notification of information (e.g. returning information) – Message Flow Rules: • All request must flow “upward” in the architectural topology • All notifications must flow “downward” – Interface Rules: • Each component’s top domain which specifies i) the set of requests that it may send upward and ii) the set of notifications to which it may react • Each components bottom domain specifies the i) the notifications it can emit downward and ii) the set of requests to which it responds C2 Discussions Component A • Each component can be attached to This is illegal only one connector, but multiple Connector 1 Connector 2 components may share a connector, it forces “substrate independence” in that you can not have a Component C Component B component run on, for instance, two different platforms. • Using the connector, components developed with different programming language and invocation methods may be Component A attached. This is legal • Provides a “layering” structure with the top-bottom and bottom-top Connector topological rules Component B Component C Distributed Object Style • Distributed Object style may be viewed as an evolution from the C2 Style, where the components are “objects” and the connector is much more functionally powerful: – The objects may run on different hosts – The objects may be programmed in different languages – The objects provide services through well defined interfaces – The connector acts as the registry/repository of services and facilitates the connections among the objects Connector Component B in Java running on HP-Unix Component C in C++ running on MS-Window remote Component A in smalltalk running on SUN CORBA: an example of Distributed Object Style • CORBA (Common Object Request Broker Architecture) is a middleware architecture produced by the Object Management Group (OMG), a consortium of about 700+ companies except for Microsoft, who went off to built Distributed Component Object Model (DCOM). – CORBA requires all interface specifications, which defines the component’s interface, to be expressed with Interface Definition Language (IDL): • Component attributes • Invocation interface (methods the interface supports) • Error processing (exceptions that are raised) – The key component of CORBA is the connector called Object Request Broker (ORB), which facilitates objects to make requests to and receive from other objects that may be local or remote CORBA (cont.) • CORBA is composed of 4 main parts: 1. Object Request Broker (ORB) “bus” 2. CORBA Services that extends the services of ORB such as concurrency service, security service, etc. 3. CORBA Facilities that extends the services for business objects such as document service for presentation 4. CORBA Business Objects that are the “components” such as customer order, customer payment, etc. Client components Client IDL stubs Server components ORB Interface Server IDL skeletons Design Recovery • Many software have evolved through multiple versions and its initial architecture and design are lost. In recovering the software architecture one should look for: • Components • Connectors and • Topology • Two major techniques that may apply are: • Syntactical Clustering – grouping of the pieces together based on “static relationship’ • Semantic clustering – grouping of the pieces based on “behavior and execution relationship” • The intent and rationale of the design may never be recovered. Design From Scratch • If there is just no nice experience of pattern or style and you are facing a “truly” novel problem that requires new solution, one may consider: – Divergence: walk away, tear down old concepts, and seek for new ideas – Transformation: review, analyze and select potential ideas from divergence – Convergence: further refining and selecting a single idea or solution By the way, this is never done in a nice sequential way! On will need to iterate. Some Suggested Techniques • Searching for analogous problem and solution in other fields (e.g. biological system) • Brainstorming by listing and expanding as much potential ideas as possible • Literature search of published material • Morphological chart by identifying the “primary” components , finding solutions for them separately and combining the sub-solutions to form a grand solution • Removing Mental Block by modifying the problem, compromise to solve a lesser problem, etc. Summarizing General Design Approach • General Techniques: – Abstraction – Separation of Concern – Modularity • Use Past Experiences: – Use design patterns – Use architectural styles • Starting from Scratch: – Make sure that previous solutions really does not apply – Search and create a new design that satisfies the problem (look to requirements carefully)