Highlights of data design and Chapter 10 Architectural Design Highlights of data design and architectural styles

Mapping OO Analysis to Design Design Patterns (domain Objects) Responsibilities Design Subsystem Design Class/Object Design Message Use Cases Object Behavior Model Class Model Object Relatio- nships Attributes Operations Collaborators

Business/Domain level Data Design - 1 Data design is defining data structures and their relationships. Business/Domain level Data Modeling (SRS) Data Warehouses Data Structures Databases Component level Application level Data warehouse: Large and independent database that has access to data stored in databases that serve a set of applications required by a specific business domain (Data Mining area).

Data Design - 2 Data design steps (at component level): - Refine data objects (from ERD or Analysis Classes of SRS) and develop a set of data abstractions (user’s view of data objects). (e.g., attributes of student data object) - Implement data object attributes as one or more data structures (this influenced by attributes, their relationships, and their use in the program). (e.g., student_record: name, ID, Address, Phone#) - Review data structures to ensure that appropriate relationships have been established. (e.g., student_record and class_list) - Simplify data structures as needed.

Software Architecture - Data Design: Represents the data component of the architecture - Architectural Design: Represents the structure of software components and their interactions (i.e., high-level organization of components and how they work together). - The architecture is not the operational! It is a representation that enables a software engineer to: 1) analyze the design effectiveness for meeting system requirements 2) consider architectural alternatives early on so that design changes can be made at low cost 3) reduce the risks associated with building the operational software. 4) facilitates ease of implementation 5) facilitates future updates 6) promote communications between all stakeholders

Architectural Styles (1) The architecture is a representation of the structure of components and their interactions. That is, how components (processing elements or modules) are organized (arranged) and how they interact with each other. An architecture (architectural style) has four elements: - Components: processing elements that transform inputs to outputs, and data components. - Connectors: the “glue” or interfaces that hold the processing elements together. - Constraints: rules of how components interact with each other. - Semantic models: information for understanding the system. (Think of house architecture regardless of it style)

Architectural Styles (2) An architectural style is a pattern of structural organization of components in the architecture. Each style requires different design details. Examples: Data-Centered Data-Flow Call-and-Return Layered OO

Data-Centered Architecture Promotes independent components (integrateability) Example: Airline reservation system

Data Flow Architecture Data transformation (pipe and filter) model. Input/output formats are required. Example: Engineering or Scientific applications

Call and Return Architecture Promotes modular design (easy to modify and scale) Can be: - Main/Sub architecture - RPC - OO Example: Any I-P-O application (survey processing)

Layered Architecture Layer of components are defined for specific tasks Example: Client/Server applications

Architectural Patterns An architectural pattern represents a repeated aspect of the style. The architectural style may include a number of patterns. Examples: Concurrency: Applications must handle multiple tasks in a manner that simulates parallelism (e.g.,OS process management pattern and task scheduler pattern) Persistence: Data persists if it survives past the execution of the process that created it. (e.g., DBMS storage and retrieval capability pattern and application level persistence pattern that builds persistence features into the application architecture) Distribution: Communicates among systems (or components of a system) in a distributed environment (e.g., a broker that acts as a “middle-man” between the client and a server)

Architectural Design - 1 1. The software must be placed into context. That is, the design should define external entities (other systems, devices, people) that the software interacts with and the nature of the interaction. See page 267 for roles. (figure 10.6, page 268) target system: Security Function uses peers homeowner Safehome Product Internet-based system surveillance function sensors control panel

Architectural Design - 2 2. Define architectural “archetypes” - An archetype is an abstraction (abstract class) that represents one element of system behavior. - They are derived from the analysis model. - They require further refinement. (figure 10.7, page 269) C o n t r l e N d D c I i a Communicates with

Architectural Design - 3 3. Define and refine software components that implement each archetype. (figure 10.8, page 270) S a f e H o m E x c u t i v r n l C M g G U I F s y p d

Architectural Design - 4 More refinement (Instantiation of Components) (Refinement of SafeHome Example) (figure 10.9, page 271) s e n o r E x t a l C m u i c M g G U I f S y p d K P h H v

Analyzing Architectural Designs - 1 Methods for evaluating alternative architectural design: - Architecture Trade-off Analysis Method (ATAM): It is six steps approach developed by SEI It is qualitative approach. It is elimination process. A set of steps is applied to alternative architectures to assess design trade-offs, and identify “sensitive points” to quality attributes. See page 272 for analysis steps. - Quantitative Guidance for Architectural Design: (not in the book) Evolving research area that focus on defining quantitative techniques for assessing quality attributes of an architecture (design dimensions: such as performance, reliability, security, maintainability, flexibility, testability, portability, interoperability, reusability, etc…).

Analyzing Architectural Designs - 2 - Architectural Complexity: It is the degree of coupling (dependency) among architecture elements (sharing, flow, constrained (control flow) dependencies) Architectural Description Language (ADL): ADLs provide syntax and semantic description of the design (diagrammatic and textual) Example ADL tools: Rapide, UniCon, ACME, Aesop, UML, … Please see Software Tools Box, page 275.

10.6: Structured Design (self-reading) Issue: There is no one particular approach for mapping requirements to design. Common approaches are Structured Design and OO Design. Structured (data-flow) design is a method for deriving Call-and-Return architecture from data flow diagrams. (i.e., using information flow for mapping requirements to design). Objective: to derive a top-down architecture that is partitioned and modular. Approach: - the DFD is mapped into a program architecture (modules) - the PSPEC and STD are used to indicate the content of each module (component level design, Ch-12)

Structured Design (self-reading) Derivation methods: - Transform Mapping: It is based on flow of data items between processes on the DFD. - Transaction Mapping: It is based on transaction flow between processes. A transaction is a data item that triggers data flow along different paths (think of a menu system). Notation: Structure chart

Mapping Method (self-reading) Program Architecture DFD Transformation Or Transaction Mapping

* Source: Software Engineering, 2nd ed., by David Budgen Design and Quality issues* The quality of the design determines the success and quality of the system to be built. A quality system is that performs required tasks within specified constraints. Unlike physical products, software design does not have physical properties that can be assessed against established measures (length, weight, height, thickness, etc…) A software design is assessed based on quality factors (called “ilities”) including reliability, efficiency, maintainability, usability. * Source: Software Engineering, 2nd ed., by David Budgen

Reliability Factor Reliability is related to the behaviour of the system. The designer tries to ensure that the system is - complete: does it handle all combinations of events and states? - consistent: is the system behavior as expected and is it repeatable? - robust: a failure in one component should not “hung” the entire system (ensure graceful termination in case of a failure) In safety-critical systems, this factors is Dominant. Multiple versions of the system (designed by different teams) may be used (auto-pilot system)

Efficiency Factor Efficiency is related to resource allocation (CPU time, memory, disk space, network access, etc…) The designer tries to predict the system needs of each identified resource. Some resources are more important than others for a particular system. Efficiency is difficult to deal with since it is based the designer's projection of resource needs from the design.

Maintainability Factor Maintainability is related to the life time of the system, which relates to its cost. The designer tries to structure the system such that future modifications are easy to conduct. Other elements that affect maintainability include names (variables and procedures), documentation standards, presentation forms, etc… Implementation (coding) also affects maintainability (Inline comments, documentation, headers, coding style, etc…)

Usability Factor Usability is related to user interface design. The designer tries to ensure that interfaces - are easy to use and navigate - provide the user with control - reduce “user memory load” - are consistent A “bad” interface makes a “good” system look “bad” from user perspective. Other factors such as testability, portability, and reusability have special purposes in specific systems.

Quality Attributes of Design Other quality factors are assessed by identifying quality attributes in the design, such as simplicity, modularity, coupling, cohesion, information hiding, accuracy, consistency, completeness, etc… For a given system and for a specific purpose (operations, update, transfer, etc…), quality attributes must be identified for each quality factors. (see examples next slides).

Example - 1 Quality factors and attributes for a real-time control system. Accuracy Completeness Consistency … Storage Organization CPU Utilization, … Modularity Structuredness … . . . Operation Revision Reliability Efficiency Maintainability Testability Purpose Quality Factor Quality Attributes

Example - 2 Quality factors and attributes for a compiler software. Purpose Quality Factor Quality Attributes Accuracy Completeness Consistency Accessibility Legibility Modularity Structuredness Machine Independence . . . Operation Revision Transfer Reliability Usability Maintainability Testability Portability Reusability

Suggested Problems 10.1, 10.3, 10.4, 10.5, and 10.6. Consider working the following problems from chapter 10, textbook, page 290: 10.1, 10.3, 10.4, 10.5, and 10.6. NO submission is required. Work them for yourself!

Last Slide End of Chapter 10