1 / 43

Illinois Institute of Technology

Illinois Institute of Technology CS487 Software Engineering Architecture III Instructor D. Lash Architectural Design The structure of data & program components need to build a system That is, the style, structure & properties of the software system

Olivia
Download Presentation

Illinois Institute of Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Illinois Institute of Technology CS487 Software Engineering Architecture III Instructor D. Lash

  2. Architectural Design • The structure of data & program components need to build a system • That is, the style, structure & properties of the software system • Software architect is a specialist often a senior level person • The architectural process looks at data designs & requirements • Considers architectural alternatives • Output an architectural model

  3. What is Software Architecture? • The structure of the system that includes • software components, their relationship and their properties. • Why important? • Enable communication between all development parties • highlight of early design decisions • an intellectually graspable model of system structure (e.g., a blueprint)

  4. Architectural Styles • Can categorize most of the software systems to use one of a Small number of architectural styles: • Data-centered • Data-flow • Call and return • Object Oriented • Layered

  5. Architectural Styles - Data-Centered • A data-state (e.g., file or DB) is in the center and accessed frequently by other components Client Software Client Software Client Software Data Store Client Software Client Software Client Software

  6. Architectural Styles - Data-Centered • Clients access the data repository. Relationship between clients and data repository can be: • Passive - clients or modules active independent to changes in data repository • Active - clients or modules are notified when their are certain changes in the data repository. • Advantages of this architecture • Integrability - easier to change and add components (because of the independence of the components). • Data storage can also serve as a messaging passing mechanism

  7. Architectural Styles - Data-Flow • Input data are transformed through a series of computational or manipulative components into output data. • Data is transmitted from one filter to next through pipes • Each filter is independent, accepts a certain input form and outputs a certain form • Each filter does not need to know about details of its neighbor. Filter Filter Filter Filter Filter Pipes

  8. Architectural Styles - Call & Return • Main program/sub-program - decompose function into a control hierarchy • main program invokes a sub-components that in turn invoke sub-sub-components • Remote Procedure Call Architectures - Distribute the main program architecture across multiple computers on network.

  9. Architectural Styles - Object Oriented • Components encapsulate data and data manipulation objects. • Communication accomplished via message passing

  10. Architectural Styles - Layered • Layers are defined that accomplish some operation • Typically the lower layers are more detailed or closer to the hardware. User Interface Application Utility Layer core

  11. Analyize Candidate Architectural Styles • There are many other architectural styles and models possible (then listed here) • SEI has an iterative process for selecting the most appropriate architecture: • Collect scenarios - establish the system from the user’s point of view - (e.g., business modeling, QFD, use cases, etc.) • Elicit requirements - that is gather requirements and requirements engineering • Describe acthitectural styles that may fit (e.g, model view for components, data flow, etc) • Identify quality attributes for each - e.g., reliability, security, maintainability, flexibility, testability, portability, reusability, interoperability). • Identify sensitivity of each style to attributes - small changes in architecture and see effect on attribute • Critique candidate architecture - find trade-off points (e.g, client/server sensitive to # clients , availability might be better w/ more servers but lower security)

  12. Mapping Requirements Into a Software Architecture • Earlier had said certain models can be mapped directing into an architectural design • methods do not exist for all architectural styles • Will look at 1 approach for the call & return architecture sometimes called structured design - origins in top-down design [WIR71], structured programming [DAH72], • SD is a data-flow oriented design method • Provides a method to go from a DFD to program structure

  13. Mapping Requirements Into a Software Architecture - SD • Structured Design has 6 basic steps 1. Establish the type of information flow 2. indicate flow boundaries 3. map the DFD into program structure 4. establish control hierarchy 5. refine using design measurers 6. refine and elaborate the design description • There are 2 different types of information flow that have different treatments • Transform flow - Overall DF in sequential manner and follows one, or only a few, “straight line” paths. (incoming, transform, output) • Transaction Flow - Info flow has a single transaction node that triggers other data flow

  14. Modular Design: Transform Flow • Transform Mapping - A set of design steps that allows a DFD with transform flow to be mapped into a specific architecture style • Transform Flow - The overall flow of data occurs in a sequential manner and follows one, or only a few, “straight line” paths. • Follows the traditional program structure • Incoming flow (input) • Transformation (processing) • Outgoing flow

  15. Modular Design:Transform Flow R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 376.

  16. Modular Design: Transform Mapping • Process 1. Review the fundamental system model - the level 0, level 1 and supporting information (e.g, requirements) 2. Review and refine data flow diagrams for the software. Add level 2 and level 3. 3. Determine whether the DFD has transform or transaction flow characteristics. 4. Isolate the transform center by specifying incoming and outgoing flow boundaries.

  17. Modular Design: Transform Mapping • Process (cont.)5. Perform “first-level factoring.” • Def. Factoring: a process of identifying control modules 6. Perform “second-level factoring.” 7. Refine the first iteration program structure using design heuristics for improved software quality. • Def. Heuristics: involving or serving as an aid to learning, discovery or problem solving by experimental and especially trial-and-error methods.

  18. control panel display control panel user commands and data display information alarm type alarm SafeHome Software telephone number tones sensor status telephone line sensor Example of a Transform Mapping R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 377.

  19. 1. Review the Fundamental System Model R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 378.

  20. 2. Review and Refine Data Flow Diagrams Lvl 3 - derived from lvl 2 for monitor sensors R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 380.

  21. 3. Determine if the DFD has Transform Flow Characteristics • Usually always have a transformation of data from Input to Output • Does the section have transaction characteristics? • A single data item triggers 1 or more information flows or • Does the area just transform (operate on) the data through it

  22. 3. Determine if the DFD has Transform Flow Characteristics Transform Center R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 378.

  23. 4. Isolate the Transform Center • Isolate the transform center by specifying the incoming and outgoing flow boundaries. • Need to select reasonable boundaries not be too concerned with exact location (e.g., in next example, invoming flow can separate read sensors and acquire response info)

  24. 4. Isolate the Transform Center Incoming flow boundary Outgoing flow boundary R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 380.

  25. Perform “First-Level Factoring • Factoring results in a program structure with top-level modules performing decision making and low-level doing I/O and computation • Middle do some control some I, O and processing • It is the factoring that will establish the call-and-return architecture • Monitor sensors executive is established to control the sub-system behavior • input controller coordinates receipt of incoming data • alarm conditions controller - supervises data operations • alarm output controller controls proper output

  26. 5. Perform “First-Level Factoring” R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 382.

  27. 6. Perform “Second-Level Factoring” • Map individual DFD bubbles (transforms) into modules • start at input move to output at transform boundary • shows 1-1 mapping • eventual refinement may change this architecture

  28. 6. Perform “Second-Level Factoring” R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 384.

  29. 7. Refine the first iteration program structure R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 385.

  30. Modular Design:Transaction Flow • Transaction Flow • Information flow is often characterized by a single data item, called a transaction, which triggers other data flow along one of many paths. • Use your menus as the transaction center. • Don’t use the external display processor as the transaction center.

  31. Modular Design: Transaction Flow R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 376.

  32. Modular Design: Transaction Flow A set of design steps that allows a DFD with transaction flow characteristics to be mapped into a predefined template for program structure.

  33. Modular Design: Transaction Mapping • Process 1. Review the fundamental system model. 2. Review and refine the data flow diagrams for the software. 3. Determine whether the DFD has transform or transaction flow characteristics. 4. Identify the transaction center and the flow characteristics along each of the action paths.

  34. Modular Design: Transaction Mapping • Process (cont.) 5. Map the DFD in a program structure amenable to transaction processing. 6. Factor and refine the transaction structure and the structure of each action path. 7. Refine the first iteration program structure using design heuristics for improved software quality.

  35. control panel display control panel user commands and data display information alarm type alarm SafeHome Software telephone number tones sensor status telephone line sensor Example of a Transaction Mapping R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 377.

  36. 1. Review the Fundamental System Model R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 378.

  37. 2. Review and Refine Data Flow Diagrams R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 380.

  38. 3. Determine if the DFD has Transaction Flow Characteristics R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 378.

  39. 4. Identify the Transaction Center and the Flow Characteristics along each of the Action Paths R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 388.

  40. 5. Map the DFD in a Program Structure Amenable to Transaction Processing R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 390.

  41. 6. Factor and Refine the Transaction Structure and the Structure of each Action Path R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 391.

  42. 7. Refine the First Iteration Program Structure using Design Heuristics for Improved Software Quality R.S. Pressman, Ph.D. Software Engineering: A Practitioner’s Approach. McGraw-Hill, New York, New York. 1997. p. 392.

  43. Refine & Document the Design • Additional documentation is generally required that describes: • a description of the processing of each module - • that is, the tasks, decisions, and I/O • the interface for each module • that is, internal module, external system and human/computer description • the global and local data structures • data type restrictions, bounding values, memory usage limitations, • design restrictions and limitations - in particular assumed design restrictions. • The design is reviewed and refinement occurs if needed

More Related