Study your flashcards anywhere!

Download the official Cram app for free >

  • Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off

How to study your flashcards.

Right/Left arrow keys: Navigate between flashcards.right arrow keyleft arrow key

Up/Down arrow keys: Flip the card between the front and back.down keyup key

H key: Show hint (3rd side).h key

A key: Read text to speech.a key


Play button


Play button




Click to flip

50 Cards in this Set

  • Front
  • Back

Design Fundamentals

creative processset of guidelines and preferably a method is necessary to provide structure to thetask in large systemsprocess of determining how a system can be built so that it will behave in themanner described in the developer centered requirements specification

Purpose of Design

specify a solution to a given problem which is essentially expressed as a functionalspecification.designer postulates a solution, models it, evaluates it against the originalrequirements and after some iteration produces the detailed specification of thesolution for the “programmer” to implement

Objectives of Design

provide blueprints (specification)– static structure of the solution– the way the pieces fit together– data objects to be used– algorithms to be used– packaging of the system

Problem Solving Process

problem– stated in requirements specificationsolution– evaluation different options– making choices using design criteria– series of trade-offs» size, speed, ease of adaptation, etc.

Ultimate criteria

Fitness of Purpose– solution should exhibit the best possible structure, but also do the required jobas well as possible within the constraintsRobustness– ability to withstand change

Wicked Problem

the solution to one of its aspects may reveal an even more serious difficulty

Design Phases

architectural design– concerned with the general structure of the solution– define the relationships among the major structural elementsinterface design– defines how the software communicates with itself, with the systems itinteracts, and with the humans who use itdetailed design– formulation of blueprints for the particular solution– refine algorithms– determine data implementation

Design Method

provides assistance with model building and with the translation processplan of action based on a set of decision making criteriasupported by diagramming and symbolic forms

Recording the Design Process

record the history of the evolution of a designin particular the reasons for making specific choices– helps with design audits and maintenance» maintenance needs to know why some choices were made and othersdiscardedincluded in the design document

Relationship to Other Activities

based on the requirementscost of maintenance is related to designPrinciples of “Good” DesignFitness of Purpose– be the best solution which works within the constraintsRobustness– able to withstand change– Lehman’s 5 Laws of System Evolution» a system has a life of its ownLaw of continuing change– a system that is used undergoes continuing change until it becomes morecost-effective to replace itLaw of increasing complexity– the disorder of a system increases unless specific work is done to maintainor reduce the “disorder”

Desirable Design Features

Simplicity– simple as possible but no simplerSeparation of Concerns– different concepts and components should be separated outInformation Hiding– information about the detailed form of such objects as data structure orinterfaces should be kept local to a module and should not be “visible”outside that unit

Characteristics of “Good” Design

implements all the explicit requirements and accommodates implicitrequirementsreadable and understandable to coders, testers and maintainersoffers a complete picture addressing data, functional and behavioral issues

Evaluate the Quality of a Design

hierarchicalmodular -- independentboth data and procedural abstractionsdriven by requirementsable to withstand change -- robust

Quality Features

External Factors– speed, reliability, correctness, usability– those things readily observed by usersInternal Factors– Fitness of Purpose– Robustness

Classification of Systems

Batch– all operating characteristics are essentially determined when it beginsprocessing one or more data streams. Any changes that occur arise becauseof the contents of the streams.Reactive– event driven, almost always asynchronous and non-deterministicConcurrent– multiple threads of execution utilizing one or more processors.– must consider scheduling, synchronization and mutual exclusionNot mutually exclusive, many systems are a combination of these

Design Principles

Abstraction– consideration of a quality apart from a particular instance– IEEE- A view of the problem that extracts the essential information relevantto a particular problem and ignores the remainder of the information– allows for the architectural and detailed design– levels of generalization– procedural -- sequence of instructions that have a specific and limitedfunction referred to as one word– data -- named collection of data that describes an object and the actionsperformed on that object (encapsulation)– control -- implies a program control mechanism w/out specifying exactmechanism for controlRefinement -- Wirth 1971– decompose the problem into more detailed instructions, continue successivelyuntil all instructions are expressed in terms of a programming languageModularity– partitioning of a system / decomposition


IEEE– The extent to which the software is composed of discrete components suchthat a change to one component has minimal impact on another.Pressman– Software is divided into separately named and addressable components calledmodules that are integrated to satisfy problem requirements

Types of Modules

Sequential– referred to and executed without interruptionIncremental– can be interrupted prior to completion and restarted at the point ofinterruption Parallel– executes simultaneously with another module in concurrent multiprocessorenvironments

Characteristics of Modular Programs

Modulesimplement a single independent functionperform a single logical tasksingle entry and single exit pointseparately testableModular Programsentirely constructed of modulescan be developed by teamsSome embedded and real-time systems cannot afford the memory and timeoverhead of modules, still use modular design and implement in-line

Software Architecture

overall structure of the softwarehierarchical structureinteraction between modulesstructure of data

Structure Chart

specialized decomposition diagram shows module invocationo not seq., repetition or selection aidso integration testing/planningo maintenance ruleso one box at top – rooto control passed down level by level and is always passed back up tothe invoking module

Control Hierarchy

fan-in -- how many modules directly control a module fan-out – how many modules does the module control superordinate -- controlling module subordinate -- controlled modulevisibility -- set of components that may be invoked or used as data by acomponent, even if indirectlyconnectivity -- set of components that are directly invoked or used as data by agiven module

Information Hiding

Parnas 1971directed towards maintenance– no propagation of errorsaids in parallel developmentmodules are designed so that implementation details are hidden from othermodules– localizes changepublic and private

Measures for assessing modules

cohesion– IEEE -- the degree to which the tasks performed by a module are functionallyrelated– relationships among the elements making up a module– interaction within a modulecoupling– IEEE -- a measure of the interdependence among modules– interaction between two modules

Goal in Designing Modules

Striving for modules which are highly cohesive (perform 1 task) and lowly coupled(independent)Yielding that any unit can be replaced by an equivalent unit with little or nochanges to other units (Robust)

Cohesion Levels

Logical Worst/Low





Functional Best/High

Coincidental Cohesion

performs multiple unrelated actionsoccurs when– “every module contain 35-50 lines of code”disadvantages– degrades maintainability– degrades understandability– not reusablerectify -- break into separate modules

Logical Cohesion

performs a series of related actions, one of which is selected by the callingmoduleusually has many parameters, not all are used in all casesinterface is difficult to understandsevere maintenance problemsdifficult to reuse

Temporal Cohesion

performs a series of actions related in timetypically each piece is more strongly related to other modulesall elements are executed at onceleads to maintenance problemspoor reusability

Procedural Cohesion

performs a series of actions related by the sequence of steps to be followed bythe productoutput of one action is the input to the nextnot reusable

Communication Cohesion

– effectively procedural cohesion except that it acts upon the same set of databetter than procedural because the actions are more closely related but still notreusable

Informational Cohesion

performs a number of actions each with its own entry point, with independentcode for each, all performed on the same data structureeach has one entry, one exitbasis of oodifferent from logical as each actions code is independent whereas in logical itsintertwined

Functional Cohesion

performs exactly one action or achieves a single goalcan be reusedeasily maintained and enhancedleads to fault isolationeasier to understand


a large program usually contains modules of different levels of cohesionin assigning levels if two or more are applicable always assign the lowest


Content Worst/High




Data Best/Low

Content Coupling

one module directly references the content of anotherexamples– module p modifies state module q– module p uses local variable of q through some math displacement– module p branches into qa change requires a changes in the bothcan’t be reused without each other

Common Coupling

both modules have access to the same global variables, same database, or readand write the same recordcommon block in FORTRANcode is unreadable, maintenance problemschange often results in side effectsexposed to more data than it needsdifficult to reuse

Control Coupling

one passes an element of control to anotherone explicitly controls the logic or sequencing of the other (logical cohesion)the two modules are not independent so poor reuse possibility

Stamp Coupling

pass data structure (array, record or pointer to structure) but the module onlyuses some of its elementsnot reusableuncontrolled data access

Data Coupling

all arguments are homogenous data itemseither simple variable or a completely used data structuredesirable goalmaintenance easierless possibility of regression fault

Design Heuristics

evaluate 1st iteration to reduce coupling and improve cohesion– explode -- increases cohesion (2 from 1)– implode -- reduces coupling (1 from 2)attempt to minimize structures with high fan-out, strive for fan-in as depthincreasesKeep scope of effect of a module within its scope of control– control -- subordinates and their subordinatesEvaluate module interfaces to reduce complexity and redundancy and improveconsistencyDefine modules predictable in function but avoid being over restrictive– internal memory leads to unpredictable– restrictions of size of local data overly restrictive and will requiremaintenanceControlled entry and exit -- single entry and exitPackage software based on design constraints and portability requirements– packaging -- assembly of software for particular environment» overlay comes into play

Quality Issues

Fitness of Purpose– does it meet the specifications– completenessRobust– designed for maintenanceAssess Quality– reviews and expert opinions– performance

Design Methods

no one method works for all classifications of systemsreason use a method– systematic means of organizing and structuring the design process– set of criteria for making choices– significant for large systems gives a common set of design goals for allparticipantsbenefits maintenance– easier to model and assess the likely effects of changes since the maintenancedesigners can understand how original designers did things and build thesame model– benefits organization of the project but does NOT provide a recipe forproducing a design

Common Characteristics of Design Methods

Translate analysis into designNotation for representation– graphicalHeuristics for refining and partitioningGuidelines for QA

Design StrategiesTop-Down Decomposition

divide and conquerfunctional decompositionfull understanding of the problem at the outset is essential, since most of theimportant decisions must be made early in the design processdifferent choices made early may result in significantly different solutions– must document choicesclearly state the intended functiondivide, connect and check the intended function by expressing it as an equivalentstructure of properly connected sub-functions, each solving part of the problemdivide, connect and check each sub-function far enough to be comfortableProblems– When to stop dividing» no firm guidelines– problem of replication and reconciliation» when more than one designer hard to recognize duplicate modulesUse as a preliminary step– separate out concurrent components– determine main modules– dividing tasks among team members


uses entities and objects and models these with the operations performed onthemgradually build the solution by adding features and viewpoints

Design Methodologies

Decomposition– based on data flow» Structured System Analysis and Structured Design (SSA/SD)» Structured Analysis and Design (SADT)– based on data structure» Jackson Method (JSP/JSD)» Warnier-Orr (LCP/LCS)Composition– object oriented (OOA/OOD)

Representation of Design

typically graphical or tabular Design Fundamentals 12Copyright © C. Tanner 2014model the problem– data flow diagram, control-flow diagram, entity-relationship diagram, usecasediagramdescribe the structure– structure chart, class diagramdescribe the logical solution– decision tables & trees, state transition diagrams & matrix, finite statemachines, PDL

Design Document

design views– decomposition description» partitions the system into design entities– dependency description» relationships between entities and system recourses– interface description» everything a designer, programmer, or tester needs to know to use thedesign entities– detail description» internal design details of the entitycan be broken into architectural and detailed design documentsuse corresponding models of the design methodmay be a section for each major component of the softwaremay correspond to different user classes– interface section for programmers and testers– quality evaluation section for QA personnel– identification section for cm personnel– detailed design section for programmers

Design Entity

identification -- unique name, used for referencing and trackingtype -- description of the kind of entity: subprogram, module, data store etc.purpose -- why entity exists, rationale for creating the entity, include any specialrequirementsfunction -- what the entity doessubordinates -- identification of all entities composing this entitydependencies -- relationship to other entitiesinterface-- how to interact with this entityresources -- elements used by this entity which are external to it Design Fundamentals 13Copyright © C. Tanner 2014processing -- rules by which the entity achieves its functiondata -- description of the data elements which are internal to the entity