CS 325: Software Engineering Lesson Six Architectural Design Software Design Objectives Software System Types Architectural Styles UML Package Diagrams Software Design Principles

Software Design Objectives When designing the structure of a software system, it is important to focus on the precise goals and priorities of the system’s stakeholders. How frequently will the system need to be modified? Are commercial off-the-shelf (COTS) parts preferred (or prohibited)? What levels of response time and performance are needed on the system? How important are reliability and data protection on the system? To what extent must the system continue to operate in the presence of software faults? If the system crashes, does the application require it to recover by returning to some previous state? CS 325 Lesson Six Architectural Design Page 53

Software System Types The design of the software system’s structure is very dependent on the type of system being developed. Interactive systems (e.g., word processors, spreadsheets) employ a client-server relationship between the user and the software. Event-driven systems (software systems using callback functions or embedded systems using hardware interrupts) are state-dependent and reactive. Transformational systems (e.g., compilers, data mining applications) consist of information processing networks that transform a sequence of input into a sequence of output. Database systems support the storage and retrieval of records, often necessitating both instantaneous access and protective security protocols. CS 325 Lesson Six Architectural Design Page 54

Architectural Styles Various generic architecture designs have arisen, and may be modified appropriately for the particular system being developed. N-Tier A strict sequence of programmed layers (e.g., HUD/Graphics/ Physics/Assets/ Libraries/OS/Platform, Open Systems Interconnection). Client-Server Clients submit requests and servers respond with service (e.g., printers, web access, file storage and retrieval). Main/Subprogram Hierarchical structure with information processing delegated to procedures and inputs transformed into outputs. Event-Driven A state-based controller receives events from various components and responds with appropriate instructions. Persistence Large numbers of objects are shared, sometimes using different formats and platforms (e.g., networked databases). Peer-To-Peer Independent components communicate in a decentralized, scalable system. Blackboard A global data repository serves as the communication medium for independent components. Cloud Computing The client-server model is extended to applications, provided dynamically as services from a number of servers. CS 325 Lesson Six Architectural Design Page 55

UML Package Diagrams To simplify complex Class Diagrams, logically related classes may be grouped into “packages” in a Package Diagram. One package depends on another (illustrated with dashed arrows) if changes in the latter might force changes in the former. CS 325 Lesson Six Architectural Design Page 56

Software Design Principles Design for Change Good designs are adaptable and easily modified. New techniques, technologies, policies, and requirements arise and must be dealt with. Separation of Concerns Concentrating on each design problem in isolation will improve both the process and the product. The process is improved by progressively focusing on high-level and then low-level design. Information Hiding Modular design enhances modifiability and reusability. Inheritance, polymorphism, and the notion of a public interface and a private implementation are also enhanced. High Cohesion In a modular hierarchy, low-level modules should be extremely relevant to the functionality of high-level modules. This level of cohesion enhances understandability, maintainability, and modifiability. Loose Coupling Modules are easier to maintain when their internal structures are independent of each other. When required to communicate with each other, modules should rely on parameters rather than shared resources. Keep It Simple, Stupid! Straightforward designs are less inclined to be misinterpreted and more inclined to be implemented correctly. Elaborate data structures and algorithms are difficult to modify and maintain. CS 325 Lesson Six Architectural Design Page 57