Presentation is loading. Please wait.

Presentation is loading. Please wait.

CS 8532: Advanced Software Engineering

Similar presentations


Presentation on theme: "CS 8532: Advanced Software Engineering"— Presentation transcript:

1 CS 8532: Advanced Software Engineering
Chapter 10 CS 8532: Advanced Software Engineering Dr. Hisham Haddad Class will start momentarily. Please Stand By …

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

3 Mapping Analysis to Design
r f a c d s g Component design Data Design Architectural Design Data Dictionary STD ERD DFD

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

5 Data Design - 2 Data design steps (at component level):
- Refine data objects (from ERD 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 is 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.

6 Data Design - 3 Few important data design principles:
- The systematic analysis principles applied to functions and behavior should also be applied to data (upfront work on data objects) - All data structures and the operations to be performed on each should be identified (define efficient operations) - A data dictionary (classes) should be established and used to define both data and program design (have more details in the dictionary (data objects)) - Low-level data design decisions should be deferred until late in the design process (abstraction in SRS, refinement during data design, implementation details during component design)

7 Data Design - 4 - The representation of data structure should be known only to those modules that must make direct use of the data (Information hiding and coupling) - A library of useful data structures and their operations should be developed (effective, robust, and reusable design) - A software design and programming language should support the specification and realization of abstract data types (know supporting features of the implementation language)

8 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 software! It is a representation that enables engineers 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

9 Why an Architecture is Important?
- Representations of software architecture promote communications between all stakeholders interested in the system. - The architecture highlights early design decisions that will have a profound impact on subsequent work and the success of the final operational system. - The architecture represents “intellectually graspable model” of how the software is structured and how components will work together. Note: architecture styles and patterns are applied software design.

10 Architectural Styles 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)

11 Taxonomy of Architectural Styles
An architectural style is the structural organization of components in the architecture. It is characterized by - type of components (data and processing elements) - type of connectors (communications among components) - constraints (restrictions and rules on data, process, and interfaces among components) - semantic models to help designers understand the properties of a system. Architectural styles represent families of software architectures. Each style requires different design details. Data-Centered, Data-Flow, Call-and-Return, Layered, and OO are just few examples of architectures styles.

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

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

14 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)

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

16 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)

17 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

18 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

19 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

20 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

21 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…).

22 Analyzing Architectural Designs - 2
- Architectural Complexity: It is the degree of coupling (dependency) among architecture elements (sharing, flow, constraints 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.

23 Structured Design - 1 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)

24 Structured Design - 2 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

25 Mapping Method DFD Program Architecture Transformation Or
Transaction Mapping

26 Flow Characteristics Transform flow boundary Transaction flow

27 Transform Mapping Steps - 1
1) Review and refine data flow diagrams. DFDs must be detailed in order to transform them into components (each process on the DFD performs one task). 2) For each DFD, isolate its transform center (DFD process(es) that transform inputs to outputs) from processes that handle inputs and outputs (draw incoming and outgoing flow boundaries). 3) Perform level-1 factoring to determine control modules This results in a high-level structure where top-level modules are control modules and low-level models are processing modules.

28 Transform Mapping Steps - 2
4) Perform level-2 factoring to determine control modules for processes that handle inputs and outputs of the transform center. This adds more components to the structure resulted in step 3. 5) Repeat those steps for each DFD to compile the first-iteration architecture. 8) Evaluate and refine the architecture as needed. Note: mapping between processes on the DFD and modules on the structure may not necessarily be one-to-one mapping. A number of processes my be transformed into one module.

29 DFD Transformation Program Architecture DFD

30 Architecture Partitioning - 1
Define separate branches of the module hierarchy for each major function. Use control modules to coordinate communication between functions function 1 function 3 function 2

31 Architecture Partitioning - 2
Define decision making and work modules. Decision making modules should reside at the top of the architecture. workers decision-makers

32 Factoring

33 Level 1 Factoring main program controller input processing output

34 Level 2 Factoring D C A B mapping from the flow boundary outward main
control

35 Transform mapping "Transform" mapping data flow model a b c d e f g h
j x1 x2 x3 x4

36 Transaction Mapping Steps
1. Isolate the incoming flow path 2. Define each of the action paths 3. Define the reception, control, and dispatch modules 4. Assess the flow on each action path (transform or transaction) 5. Map processes of each action path individually to the corresponding modules

37 Transaction Flow T incoming flow action path

38 Transaction Mapping Data flow model mapping program structure a b t g
h d e f i k j l m n Data flow model x1 x2 x3 x4 x3.1 mapping program structure

39 Level 1 DFD Error message Fixture setting select report report
operator fixture servos display screen generate analyze status send control value determine command type read commands Fixture setting assembly record Error message Valid select report control robot report robot control

40 Level 2 DFD - Isolate Flow Paths
read command validate determine type record calculate output values format report produce error msg fixture status setting send control value invalid command combined raw setting fixture setting robot control start/stop assembly valid command

41 each of the action paths must be expanded further
Map The Flow Model process operator commands command input controller read validate produce error message determine type fixture status report generation send control value each of the action paths must be expanded further

42 Refine The Structure Chart
process operator commands command input controller read validate produce error message determine type send control value fixture status setting format record calculate output values report generation

43 Example Processing Narrative
Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen. When robot control switches are selected, control values are sent to the robot control system. Process operator command software reads operator commands from the cell . An error message is displayed for invalid commands . The command type determined valid commands and appropriate action is taken . When fixture commands are encountered , fixture status analyzed and a fixture setting output to the fixture servos When a report selected, the assembly record file read and a report is generated and on the operator display screen When robot control switches selected control value s are sent to robot control system. parse noun-verb

44 Then what? Once an architecture is derived,
- write process narrative for each module (tasks, data structures, I/O, constraints/limitations (data types, format, timing, memory, data value ranges, special data/cases boundaries processing). - write interface description for each module and entity. - describe local and global data structures the module needs access to. - conduct design reviews and refine it as needed. Focus on smaller number of modules (with high cohesion and low coupling) and simple data structures.

45 * 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

46 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)

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

48 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…)

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

50 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).

51 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

52 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

53 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!


Download ppt "CS 8532: Advanced Software Engineering"

Similar presentations


Ads by Google