Designing Software Architecture

1. 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!

2. 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.

3. 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

4. Design Activities are Not Straightforward Increases in difficulty • One may wonder around a while in the beginning to get started: • 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

5. Any Help? • Some “Basic” Design Approach/Tool: • Abstraction • Separation of Concern • Decomposition/Composition (my words) • These concepts are not totally separate

6. 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. • The generalization from the details and the specifics “SHAPES” A B S T R A C T I O N 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”.

7. 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”)

8. Levels of Abstraction Decomposition & Composition SHAPES Red arrow = decomposition Blue arrow = composition “2-D” shapes Ovals Arrows Triangles

9. 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 .

10. 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

11. 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.

12. Any Other Help in Designing Architecture? • Just as in other fields, past experiencesprovide 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”

13. A Broad View of Styles & Patterns deep Domain Specific Software Architecture some combine these into “styles” Architectural patterns Design Styles we focus on these 3 App Domain Knowledge Design patterns mostly for OO detail design & programming shallow programming level software design component level Software System level Scope Applicability

14. Domain Specific Software Architecture (DSSA) • Domain Specific Software Architecture contains a substantial amount of information based on past experiences within the specific application domain: • a reference architecture for a specific domain, • a library of software components containing reusable chunks of domain expertise, and • a method of choosing and configuringcomponents to work within an instance of the reference architecture. (1) reference architecture for domain x Domain core (2) domain components (3) “Core must be a part of every instance and -------”

15. 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)

16. 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 request Database (State) User Interface (Display) Business Logic (Logic) response response the software components may be distributed across hardware

17. 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) Model View Controller

18. Today’s Popular Model with JSPfor dynamic presentation content 1 JSP Browser 4 Data Base/ enterprise system 2 3 Java Bean (Simplemodel - more complex JSP) Servlet (controller) 1 2 Data Base/ enterprise system 4 Browser 3 Java Bean (model) JSP (view) 5 6 (Model-View-Controller (MVC)model - separate controller from view)

19. 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. Compute control B sensor 1 control C sensor 2 control D sensor 3 control A Even though arrows go from sensors to compute, it could becompute polling the sensors.

20. Architectural Styles Recall, design decisions address: 1. elements and their arrangements 2. behavior of elements 3. interactions of elements 4. non-functional properties 5. implementation guidelines An Architectural Style descriptively defines a particular codification of design elements and formal arrangements. It prescriptivelyconstrains the kinds of design elements and their arrangements. (It definesand limits the structure --- my words) • Architectural styles covers the “broadest” lessons and experiences that are used in software design. It reflects less domain knowledge and is higher than programming constructs. It is a named collection of design decisions that: • 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

21. 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

22. Traditional Language-Influenced Style • This is based on a “main component” that calls upon functional “sub-components” • Traditional programming paradigm • Software decomposedinto 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.

23. Layered Style Layer 1 Prog. A Layer 2 Prog. C Prog. B Layer 3 Prog. D any advantage or disadvantage ? ---- think of performacne, error location, secuioryt, etc. • 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.

24. Operating System Example of Layered Style Applications Programs Operating System Services print “ Hi” Hardware Interrupts & Kernel Services process scheduler printer service HP Device I/O Cross layer Within layer

25. Dataflow Style regional daily transactions Master File sorted daily transactions update Master file regional daily transactions sort/merge by accnt. # regional daily transactions • 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) these “transactions” may be credit cards, stocks, etc. --- advantage/disadvantage?

26. Shared-State or Shared-Data Style Strongly Data Coupled ! a) Risks? b) Advantages? Component A Component D Shared Repository Component B Component E Component C • 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

27. 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

28. 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

29. Peer-Peer Style • A network of “loosely-coupled” autonomouscomponents, 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.

30. 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 componentsare: • C2 (component and connectors) Style • Distributed ObjectStyle

31. C2 (Components and Connectors) Style Component A Component A Connector 1 Connector 2 • This styles allows various componentsto 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 B Component C

32. 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

33. C2 Discussions Component A This is illegal Connector 1 Connector 2 Component C Component B Component A This is legal Connector Component C Component B • Each component can be attached to only one connector, but multiple components may share a connector, it forces “substrate independence” in that you can not have a component run on, for instance, two different platforms. • Using the connector, components developed with different programming language and invocation methods may be attached. • Provides a “layering” structure with the top-bottom and bottom-top topological rules

34. Distributed Object Style Connector remote Component B in Java running on HP-Unix Component C in C++ running on MS-Window Component A in smalltalk running on SUN • 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

35. 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

36. CORBA (cont.) Client components Server components ORB Interface Server IDL skeletons Client IDL stubs Object Request Broker (ORB) which is the transportation “bus” and also contains a few local services such as object reference to string conversion • CORBA is composed of 4 main parts: • Object Request Broker (ORB) “bus” • CORBA Services that extends the services of ORB such as concurrency service, security service, etc. • CORBA Facilities that extends the services for business objects such as document service for presentation • CORBA Business Objects that are the “components” such as customer order, customer payment, etc.

37. 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 rationaleof the design may never be recovered.

38. 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.

39. 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.

40. 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)