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

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

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

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

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

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