Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
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 |
|
|
Modularity |
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 Temporal Procedural Communication Informational 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 |
|
|
Cohesion |
a large program usually contains modules of different levels of cohesionin assigning levels if two or more are applicable always assign the lowest |
|
|
Coupling |
Content Worst/High Common Control Stamp 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 |
|
|
Composition |
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 |
