Lecture 17to18-System Design
Page 1: Title
Designing System Architecture
Muhammad Zeeshan Nazar
Page 2: The Design Process
Design Overview
Definition: The creative process of determining how to fulfill customer requirements.
Resulting plan is known as the design.
Design Phases
Early design decisions: Address the system’s architecture.
Later design decisions: Focus on implementing individual units.
Page 3: Translating Requirements to Design
Component-Level Design
Scenario-based elements:
Use cases (text, diagrams, activity diagrams, swimlane diagrams)
Analysis Model:
Class-based elements, class diagrams, analysis packages, CRC models, collaboration diagrams
Behavioral elements:
State diagrams, sequence diagrams
Interface Design
Architectural Design
Data/Class Design
Design Model
Page 4: Design or Requirements?
Key requirements for physical spaces:
A room for three children to play and sleep separately
A room for parents
Cooking area
Heating and cooling requirements
Indoor water and electricity
Page 5: Multiple Designs?
Considerations for architectural options:
Maximizing and minimizing play areas or bedroom sizes
House structure (one or two stories)
Evaluate which design is optimal
Impact of proposed solutions on requirements.
Page 6: The Design Process
Design as a Creative Process
Design involves creativity and addressing numerous constraints.
Incorporates nonfunctional design goals (e.g., usability, maintenance).
External factors include standards, regulations.
Improving Design
Learn from examples of effective designs.
Most design is routine—solving problems by reusing solutions from prior situations.
Page 7: Leveraging Existing Solutions
Techniques to utilize pre-existing designs:
Cloning: Adapting existing designs/codes with minor changes
Reference Models: Generic architectures suggesting how to decompose systems.
Page 8: Reference Models as a Concept
Example: Reference model for a compiler
KEY Components:
Data store, fetch/store, symbols, control flow, lexical analyzer, parser, etc.
Page 9: Architectural Styles
Challenges with existing reference models.
Architectural Styles: Generic solutions addressing specific software architectures.
Important to select and integrate multiple styles to achieve the desired outcome.
Page 10: Design as an Iterative Process
Design Iteration
Designers cycle through understanding requirements, proposing solutions, testing feasibility, and documenting designs for programmers.
Final Outcome
Delivery of the Software Architecture Document (SAD).
Page 11: Decomposition and Views
High-level structure of system elements
Creating a detailed hierarchy for information and problem isolation.
Page 12: Popular Design Methods
Importance of decomposition to identify key problems
Methods include functional, feature-oriented, data-oriented, event-oriented, and object-oriented designs.
Page 13: Functional Decomposition
Dividing functions into modules based on requirements:
Initial functions in requirements are broken down into subfunctions and assigned to modules.
Page 14: Functional Decomposition and Systems
Example usage in systems such as submission verification and management.
Modular architecture enhances organization of software units.
Page 15: Example: Student Registration System
Components of the system include:
Data entry validation, transaction verification, report generation, etc.
Clearly defined inputs and outputs for each module.
Page 16: Characteristics of Modular Design
Definition of a modular design:
Ensures each activity performed by a single software unit with well-defined interfaces.
Page 17: Component-Based Software Engineering
Definition: Systems created by integrating pre-existing components.
Components defined as self-contained software with clear interfaces.
Goals include speeding up development and simplifying maintenance.
Current state of research for optimal implementation.
Page 18: Architectural Styles
Key Styles:
Pipe-and-Filter, Client-Server, Peer-to-Peer, Publish-Subscribe, Repositories, Layering.
Page 19: Pipe-and-Filter Architecture
Description of how data flows through pipes and transformations occur via filters.
Page 20: Properties of Pipe-and-Filter
Benefits of this architecture include:
Understanding system effects, reusability of filters, ease of evolution.
Drawbacks:
Not suited for interactive applications.
Page 21: Client-Server Architecture
Two main components: servers providing services and clients accessing them through protocols.
Clients can send executable functions to servers via callbacks.
Page 22: Peer-to-Peer Architecture
Characteristics:
Each component functions as both client and server, facilitating requests.
Offers scalability and resilience to failures.
Examples include Napster, Kaaza, BitTorrent.
Page 23: When NOT to Use P2P
Limitations of P2P:
Frequent file changes, speed critical for sharing, essential file quality, and trust issues among peers.
Page 24: Publish-Subscribe Mechanism
Component interaction through broadcasting and event subscriptions.
Characteristics: Supports evolution, customization, but requires shared repository.
Page 25: Repositories Architecture
Structure includes a central data store and component accessors.
Challenges: Ensuring effective interaction between components.
Page 26: Openness in Repositories
Data representation must cater to various programmers to access the repository, posing integration challenges.
Page 27: Layering in Architecture
Hierarchical layers with each providing services to the outer layer while acting as a client to the inner layer.
Advantages: High abstraction and ease of modification.
Disadvantages: Complexity in structuring layers can impact performance.
Page 28: Example of Layered Architecture
System Components:
User interface, application, utility, and core layers.
Page 29: Call and Return Architecture
Structures involving main program/sub-program relationships and remote calls.
Page 30: Combining Architectural Styles
Real-world architectures often blend multiple styles.
Flexibility to use different styles at various layers.
Page 31: Architectural Styles Examples
Combination possibilities: Client-server, publish-subscribe, layering, and repositories within enterprise systems.
Page 32: Example: World Cup System
Overview of the architecture implemented during the 1994 World Cup, featuring central control and local distribution.
Setup included a central Texas database for management and 160 Sun workstations.
Page 33: Sidebar: Napster’s P2P Architecture
Description of the technical challenges and architecture used in Napster’s P2P system, focusing on user interactions and server organization.
Page 34: References
UCF slides for SE course
SE books by Pressman, Pfleeger, and Sommerville.