Chapter 7: Design Architecture And Methodology

Chapter 7 Design Architecture And Methodology

Chapter 7: Design: Architecture and Methodology 1 Design Topics Covered Architectural vs. detailed design “Common†architectural styles, tactics, and reference architectures Basic techniques for detailed design Basic issues with user-interface design 2 Design Starts mostly from/with requirements (evolving mostly from functionalities and other non-functional characteristics). How is the software solution going to be structured? What are the main components—(functional comp)? Often directly from requirements’ functionalities (use cases). How are these components related? Possibly re-organize the components (composition/decomposition). Two main levels of design: Architectural (high level) Detailed design How should we depict design—notation/language? 3 Relationship between Architecture and Design Detailed Design Comes from Requirements & Architecture 4 Software Architecture Structure(s) of the solution, comprising: Major software elements Their externally visible properties Relationships among elements Every software system has an architecture. May have multiple structures! Multiple ways of organizing elements, depending on the perspective External properties of components (and modules) Component (module) interfaces Component (module) interactions, rather than internals of components and modules 5 Views and Viewpoints View – representation of a system structure 4+1 views (by Krutchen) Logical (OO decomposition – key abstractions) Process (run-time, concurrency/distribution of functions) Subsystem decomposition Physical architecture +1: use cases Other classification (Bass, Clements, Kazman) Module Run-time Allocation (mapping to development environment) Different views for different people 6 Architectural Styles/Patterns Pipes and filters Event driven Client-server Model-view-controller (MVC) Layered Database centric Three tier We discuss architectural styles/patterns as “reusable†starting point for design activities. 7 Pipe-Filter Architecture Style The high-level design solution is decomposed into two “generic†parts (filters and pipes): Filter is a service that transforms a stream of input data into a stream of output data. Pipe is a mechanism or conduit through which the data flows from one filter to another. Input time cards Prepare for check processing Process checks Problems that require batch file processing seem to fit this architecture: e.g., payroll, compilers, month-end accounting. Reminds one of DFD without the data store or source sink. 8 Event Driven (Real Time) The high-level design solution is based on an event dispatcher, which manages events and the functionalities that depend on those events. These have the following characteristics: Events may be a simple notification or may include associated data. Events may be prioritized or be based on constraints such as time. Events may require synchronous or asynchronous processing. Events may be “registered†or “unregistered†by components. Personal (device) dispatcher voice call text msg Image keypad Phone processing Text processing Image processing Problems that fit this architecture include real-time systems such as: airplane control, medical equipment monitor, home monitor, embedded device controller, game, etc. - - - Try a commercial flight control system - - - 9 Basic Client-Server Style Application split into client component and server component. 10 Client-Server Style Client may connect to more than one server (servers are usually independent). 11 Separates model (data) from view. Controller often integrated with view nowadays. Model-View-Control (MVC) Style Most internet web applications fall under this style. 12 The “outer†layer can only ask for service from the “inner†layer; the “upper†layer can only ask for service from the “lower†layer. − Strict layering: only directly inside or below layers − Relaxed layering: any inside or below layers Layered Style 13 Shared Data (DB)-Centric Style Very popular within the business applications community 14 Three-Tier Style (Mixture) Clients do not access DB directly. Better flexibility, integrity. (Why?) Reminds one of client server or MVC. 15 Architectural Tactics Tactics (in contrast to architectural style) are for solving “smaller, specific†problems. Do not affect overall structure of system. Example: we add specific functionalities or component (e.g., to increase reliability) in the design for fault detection—especially for distributed systems: Heartbeat Ping/echo 16 Reference Architectures Full-fledged architectures. Serve as “templates†or as “a reference†for a class of systems. Example: J2EE reference architecture (MVC2). There also are “application domain−specific†reference architectures. 17 Detailed Design Further refine architecture and match with requirements. How detailed? How formal? Maybe of different levels of detail for different views. 18 Functional Decomposition Technique Dates back to “structured programming†[now (non-OO) Web apps with PHP tool]. Start with: main (task/requirements) --> module. Refine into sub-modules. There are alternative decompositions. 19 Possible Decomposition of (Student-Course Management App) 20 “Alternative†Decomposition/Composition 21 Relational Database Design Most databases use relational technology. Relations (tables): Two-dimensional sets Rows (tuples), columns (attributes). A row may be an entity; columns may be relationships or attributes. Primary key (unique identifier) – for search. Foreign keys (connects tables) 22 Database Design Conceptual modeling (done during analysis/requirement phase) produces ER diagram. Logical design (to relational). Physical design (decide data types, etc.). Deployment/maintenance: Low-level physical (which hard drive, etc.) Adjustment of indexes 23 Entity-Relationship Diagrams Entities (rectangles) Weak: double lines Relationships (diamonds) Attributes (ovals) Multi-valued: double lines Identifying: underlined 24 ER Diagram Example 25 Logical DB Design – Entities Table per entity. Flatten composite attributes. For weak entities, add the primary key of the strong entity. 26 Logical DB Design – Multi-Valued New table needed for multi-valued attributes. 27 Logical DB Design – Relationships If one side related to just one entity, add foreign key to that side. For many to many, need new table. For ternary, need new table. 28 Physical DB Design Data types for each attribute. Check which ones your DBMS support. Encoding. Decide on indexes. Searches are faster, updates are slower. Indexes consume space. Can always adjust during deployment. Denormalization done sometimes (avoid). 29 OO Design First step: review and refine use cases. Decide: Which classes to create How are the classes related Use UML as the design language. 30 Use Case Diagram 31 Class Design Classes represent real-world entities or system concepts. Organized into classes: objects in a class have similar characteristics. Classes have properties (attributes or data). Classes also have methods (perform functions). 32 UML Class Diagrams Association Composition Use “no-fill†diamond for aggregation. 33 UML Class Diagrams – Inheritance 34 UML State Diagram depicting a student’s “status†in school 35 UML “Sequence Diagram†used to depict a flow of interactions 36 User Interface Design Most apparent to the user Two main issues: Flow of interactions ii) Look and feel Types of interfaces Command-line Text menus Graphical (GUI) 37 Flow of Interactions Prototype screens Registration: Select term. Registration: shows term. Select first course. Registration: shows term, course(s) with schedule and cost. Select Additional course; Delete course; *Finish registration. Registration: shows final schedule. Select Confirm or Cancel. 38 High Fidelity Prototype 39 User: Screens: Process: User Interaction Added to the Sequence Diagram 41 Norman’s 7 Stage Model 42 The GOMS Model (an “advanced†topic for UI) Consider different kinds of users. Four factors (for the kind of user) Goals of the user Operations provided by the system Methods or the sequence of operations Selection rules for the methods 43 Other UI Issues Kinds of users Heuristics UI guidelines Multicultural issues Metaphors Multiplatform software Accessibility Multimedia interfaces 44 HTML Script Simple Example 45 Model-View-Controller (MVC) Software Project Model SQL database View HTML Controller PHP 46 Object-Relational Impedance Mismatch (an “advanced†topic) How do we handle mismatches between object-oriented concepts and relational DB such as: Typing Private and public Inheritance and polymorphism Nested structure versus table structure

Paper For Above instruction

Design architecture and methodology are critical facets of software engineering, shaping the structure, quality, and maintainability of software systems. Effective design begins with a clear understanding of requirements, both functional and non-functional, providing the foundation for architectural decisions and detailed design processes. This paper explores the fundamental concepts of software design, focusing on architectural styles, view representations, and refinement techniques that ensure robust and flexible software solutions.

Architectural vs. Detailed Design

Architectural design constitutes the high-level framework of a system, defining its major components, their relationships, and external properties. It embodies the overarching structure that supports system requirements and facilitates stakeholder communication. Conversely, detailed design zooms into the specifics of individual components, specifying algorithms, data structures, and interface details. Both levels are interconnected; detailed design derives from and refines the architectural blueprint, aligning with functional and non-functional requirements.

Relationship Between Architecture and Design

The architecture provides a blueprint that guides detailed design, ensuring consistency and coherence across the system. It encapsulates critical decisions about component decomposition, connectivity, and data flow, which are then elaborated upon during detailed design. This two-tiered process helps manage complexity, promote reuse, and accommodate evolving requirements. As Booch (2007) argues, system architecture serves as the backbone for system development and evolution.

Software Architecture: Structures and Views

Software architecture involves defining various structural views of a system, which include logical, process, subsystem, and physical architectures. Kruchten’s 4+1 View Model (Kruchten, 1995) articulates these perspectives to address different stakeholder concerns: the logical view focuses on object decomposition, whereas the process view addresses runtime concurrency. Subsystem views break down the system into manageable modules, while physical views depict deployment and hardware considerations. Multiple structures enable different aspects of the system to be analyzed and optimized.

Architectural Styles and Patterns

Architectural styles, or patterns, dictate how components are organized and interact. Classic examples include pipes and filters, event-driven, client-server, Model-View-Controller (MVC), layered, and database-centric architectures. Each style caters to specific system needs; for instance, pipes and filters are suitable for batch processing systems like compilers, while event-driven architectures excel in real-time embedded systems. These styles promote reuse and facilitate communication among stakeholders.

Selected Architectural Styles

• Pipe-Filter: Decomposes processing into independent filters connected through pipes, ideal for batch-processing tasks like payroll systems.
• Event-Driven: Reacts to external or internal events, suited for real-time systems such as flight control or medical instrumentation.
• Client-Server: Divides application into client and server components, supporting distributed computing environments.
• MVC: Separates concerns in web applications, fostering modularity by decoupling data, user interface, and control logic (Gamma et al., 1995).
• Layered Architecture: Implements strict or relaxed layering to ensure controlled interactions, often used in enterprise applications.

Architectural Tactics and Reference Architectures

Architectural tactics address specific quality concerns, such as reliability, security, or scalability, without altering the core architecture. For example, fault detection techniques like heartbeat mechanisms enhance system reliability. Reference architectures serve as templates or standards, exemplified by the J2EE MVC2 architecture, guiding developers in implementing consistent solutions across domains.

Detailed Design and Decomposition Techniques

Refining the architecture involves functional decomposition, where the system is broken down into modules and sub-modules based on functionalities, often visualized through diagrams like data flow diagrams (DFD) or structured programming methods. Alternatives include object-oriented class-based designs, employing UML diagrams such as class and sequence diagrams to depict interactions and hierarchies (Rumbaugh et al., 1991).

Database Design and Implementation

Relational database design follows a systematic process involving conceptual modeling via Entity-Relationship (ER) diagrams, logical schema creation, and physical implementation. ER diagrams illustrate entities, attributes, and relationships, providing a blueprint for logical data organization. Logical design involves defining primary and foreign keys, while physical design addresses data types, indexing, and storage considerations to optimize performance and integrity (Elmasri & Navathe, 2015).

Object-Oriented Design and UML

Object-oriented design leverages UML to model real-world entities and their interactions. Class diagrams specify attributes and operations, while inheritance, associations, and aggregation capture relationships among classes. State diagrams and sequence diagrams further detail object behaviors and interactions (Booch, 2007). This approach supports modular, reusable, and adaptable system development.

User Interface Design and Usability

Designing effective user interfaces (UI) prioritizes workflow, usability, and aesthetics. Techniques involve prototyping, usability testing, and adherence to heuristics, such as Norman’s seven stages of action (Norman, 2013). Interfaces may be command-line, graphical, or web-based, with considerations for accessibility and multicultural usability. Interaction flows are mapped via prototypes and sequence diagrams, enabling iterative refinement.

Web and Application UI Patterns

Implementing UI patterns like Model-View-Controller (MVC) separates data, presentation, and control logic, facilitating maintainability and scalability (Gamma et al., 1995). The MVC pattern is prevalent in web development using technologies such as PHP and SQL databases. Additionally, UI design must address the object-relational impedance mismatch, ensuring consistency between object models and relational databases (Fowler, 2003).

Conclusion

Software design architecture and methodology encompass high-level structural decisions and detailed implementation techniques. Employing suitable architectural styles and views helps accommodate various stakeholder perspectives and quality attributes. Refinement through decomposition, modeling, and UI design ensures the creation of robust, maintainable, and user-friendly systems. As software complexity grows, systematic approaches to architecture and design become increasingly vital in delivering successful software solutions.

References

• Booch, G. (2007). Object-Oriented Design with Applications. Addison-Wesley.
• Elmasri, R., & Navathe, S. B. (2015). Fundamentals of Database Systems (7th ed.). Pearson.
• Fowler, M. (2003). Patterns of Enterprise Application Architecture. Addison-Wesley.
• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software, 12(6), 42–50.
• Norman, D. A. (2013). The Design of Everyday Things. Basic Books.
• Rumbaugh, J., Jacobson, I., & Booch, G. (1991). The Unified Modeling Language User Guide. Addison-Wesley.