Illinois institute of technology l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 43

Illinois Institute of Technology PowerPoint PPT Presentation


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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Illinois institute of technology l.jpg

Illinois Institute of Technology

CS487

Software Engineering

Architecture III

Instructor D. Lash


Architectural design l.jpg

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


What is software architecture l.jpg

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)


Architectural styles l.jpg

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


Architectural styles data centered l.jpg

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


Architectural styles data centered6 l.jpg

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


Architectural styles data flow l.jpg

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


Architectural styles call return l.jpg

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.


Architectural styles object oriented l.jpg

Architectural Styles - Object Oriented

  • Components encapsulate data and data manipulation objects.

    • Communication accomplished via message passing


Architectural styles layered l.jpg

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


Analyize candidate architectural styles l.jpg

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)


Mapping requirements into a software architecture l.jpg

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


Mapping requirements into a software architecture sd l.jpg

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


Modular design transform flow l.jpg

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


Modular design transform flow15 l.jpg

Modular Design:Transform Flow

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


Modular design transform mapping l.jpg

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.


Modular design transform mapping17 l.jpg

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.


Example of a transform mapping l.jpg

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.


1 review the fundamental system model l.jpg

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.


2 review and refine data flow diagrams l.jpg

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.


3 determine if the dfd has transform flow characteristics l.jpg

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


3 determine if the dfd has transform flow characteristics22 l.jpg

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.


4 isolate the transform center l.jpg

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)


4 isolate the transform center24 l.jpg

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.


Perform first level factoring l.jpg

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


5 perform first level factoring l.jpg

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.


6 perform second level factoring l.jpg

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


6 perform second level factoring28 l.jpg

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.


7 refine the first iteration program structure l.jpg

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.


Modular design transaction flow l.jpg

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.


Modular design transaction flow31 l.jpg

Modular Design: Transaction Flow

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


Modular design transaction flow32 l.jpg

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.


Modular design transaction mapping l.jpg

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.


Modular design transaction mapping34 l.jpg

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.


Example of a transaction mapping l.jpg

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.


1 review the fundamental system model36 l.jpg

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.


2 review and refine data flow diagrams37 l.jpg

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.


3 determine if the dfd has transaction flow characteristics l.jpg

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.


4 identify the transaction center and the flow characteristics along each of the action paths l.jpg

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.


5 map the dfd in a program structure amenable to transaction processing l.jpg

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.


6 factor and refine the transaction structure and the structure of each action path l.jpg

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.


Slide42 l.jpg

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.


Refine document the design l.jpg

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


  • Login