Design Flashcards
Design
deliberate, purposeful planning
Engineering
Skillful or artful contrivance applying scientific and mathematical principles
Craft
skilled occupation
Art
use of skill, taste, and imagination in the production of aesthetic objects
What’s the difference between software design and programming
Scale - When you’re doing design, it’s typically because you have a Big problem that needs a Big solution
Emphasis on Non Functional Requirements - Programmers may be concerned with things like performance and other things that don’t play a big role.
Software Design
Building a program while satisfying a problem’s functional requirements and not violating its non-functional constraints
Two Phases of Software Design
- Architectural Design
- Detail Design
Architectural Design
The process of identifying and assigning the responsibility for aspects of behavior to various modules or components of a software
Detail Design
The process of specifying the behavior of each of the system components that you’ve identified during architectural design
Psuedo Code
PDL (Program Design Language)
Keywords, free syntax of natural language, data declaration, subprogram definition and calling
Structured Programming
Sequence, condition, repetition; chunking
Flowcharts; call graphs
Directed graphs: node is computational unit; arc is flow of control
Decision tables
Rules, conditions, actions
Design Method
Systematic sequence of steps that a design team uses to solve a problem
Generally a design method suggests a particular way of viewing a problem (OO views problem from a set of cooperating objects)
Structure Design and Role based design are others.
Consequences of testing a design first once the project is done?
Not cost or time efficient.
The earlier you find problems, the less expensive they are to fix them.
Especially if you have a design problem and it goes unnoticed until right before release.
3 Common Aspects of Design Approaches
- Method
- Representation
- Validation
Design Representation
Some kind of review, walkthru, or inspection by a team or tool to validate the design’s legality and legitimacy
Independence of Validators
Have a team that did the work also do the review can lead to that team being blind from some issues
Dependence of Design Validation on Design Method
Some methods (Structured Design) list important metrics and other resources that determine how legitimate a design is
On-Going vs After-the-Fact
When do you do design validation?
On-Going: Do it as you go along, like on a daily or weekly basis review your work and make adjustments
After-the-Fact: Wait for major milestones, perform the review, and then make adjustments
Functional Behavior vs Non Functional Constraints
Separating the differences between what the application does do vs how the application does it.
Specification vs Design
Specification/What vs Design/How
Specification lays out What the software should do, the Design process begins to answer How it does that
Application Specificity
What is it about your particular application that is going to affect the design process?
(Do you have existing resources you want to use to create the software? This affects)
Traditional Design Documentation
Subcomponents
- Processes/activities
- Data / Data flows
Control Flow
- Control Regime
Performance
Resources/Consumption
Leonardo Project
Project from the 80s that sought to determine what a suitable set of Design information looks like
Leonardo Object Additions
Stakeholders: their views/interests; work procedures
Issue Base: logged issues as they come up along with their theoretical possible resolutions
Temporal Relations: Versioning, histories, schedules, transformations
Constraints: internal or external
Aggregates: Design or implementation artifacts like config files, packages, and components
Design Rationale
The reasons one did what they did for a design.
Why someone makes their Design Decisions.
Design Decisions
Explicit choices of how to trade off two non-functional aspects of a design
(speed vs size)
Coupling
The extent to which two components depend on each other for successful execution.
(Low coupling is good)
Cohesion
The extent to which a component has a single purpose or function.
(High cohesion is good)
Do “Java packages” support high cohesion or low coupling?
Low coupling
Does Java inheritance mechanism increase or decrease coupling between the parent and child?
Increase coupling
Information Hiding
Implementing the nitty gritty details behind an Abstraction Interface that the implementer interface with. This allows for devs to change the implementation details more freely.
Declarative Abstraction
Creating abstraction around what the problem is, and not how to solve it
Aggregation Abstractions
Arrays, Structs, Objects that are containers pre-defined allowing a dev to avoid implementation themselves
Generalization Abstractions
Creating objects or classes that allow you to create base functionality ignoring all the special cases
Parameterization Abstract
Defining explicit parameters helps you abstract away all the possibilities that exist if they were undefined
Non-determinism Abstraction
Leaving choices unspecified
Descartes Design Philosophy
Analysis; use of models
Marx Design Philosophy
Understanding the social context of design solutions; user-centered design
Heidegger Design Philosophy
tools for accomplishing goals; CASE, IDE
Wittgenstein Design Philosophy
language games, desktop metaphor
