# Module 2 Summary
## Overview
### Software Design
- Describe the contents of a software design
- Explain the enabling techniques (common principles) for design
- Explain common design viewpoints
- Identify different architectural styles and the types of applications
they are appropriate for
- Understand what a software design pattern is and explain the use of the
device, and publish/subscribe patterns
- Describe how to evaluate the quality of a design
- Understand how to perform a design review
- Create uml class, sequence and state diagrams
### Software Construction
- Explain issues in reusing software
- Understand factors that affect software reusability
- Explain the need for software configuration management (SCM)
- Describe the 4 SCM activities
- Describe capabilities of SCM tools
- Define software configuration terminology (CCB, build, release,
configuration item, version)
- Identify benefits of utilizing open source software
- Identify factors to consider in selecting open source components
------
## Software Design
### Lecture 1
In the big picture, we start with system requirements, then system
design, then software requirements, and then software design.
Another term we hear a lot is "software architecture" and "software
architects."
- Create plans/blueprints
- How to solve the customer's requirements and find a way to
conceptualize that that can be implemented by a software engineer
How do you train a (building) architect? What do you teach them?
- _Patterns!_
- Business/economics (understand cost, economics, etc.)
- Constraints (laws, regulations, etc.)
- Quality attributes
_Software architecture_: the structure which comprises the software
elements, externally visible properties of those elements, and the
, relationships among them.
- Software elements: modules, components, entire programs, systems,
services (viewed as "black boxes")
**Architecture Importance**
- Critical to quality of the system (and its assessment)
- Errors are costly (if we create architectural errors, they are very
costly to eventually fix)
- Changes (assess impact of making changes)
- Communication vehicle (stakeholders, development team, integration-test
team, management and customers supporting ideas of estimation, schedule,
cost, and tracking)
**History**
- 1970's: Top-down design; attempt to solve a problem by breaking it into
functions, then subfunctions, etc.; problem decomposition
- 1980's: Data-flow design; in additional to a functional decomp, we were
also taking into account information flow; if we could understand those
flows, maybe we could better optimize those flows
- 1990's: Object-oriented design
- 2000's: services; service-oriented architecture
**Design Principles**
- Iterative: design is iterative; consider it along the lines of doing a
term paper right
- Objective for paper (persuasive? informative?)
- Outline
- Key points
- Key paragraphs
- (Drafting!)
- Finalize
- Traceability: important to trace design aspects to requirements; all
requirements need to be traced to elements of the design
- Reflect problem domain: if we're trying to solve a problem, we would
like to be able to have the design elements map to the problem
domain/system ("conceptual modeling")
- Maintainable
- Do *NOT* contain implementation details: abstract; provide flexibility
- Manage complexity: not to create the most complicated architecture;
keep it simple, stupid
- Minimize coupling (connections between components)
- Maximize cohesion (each elements are well-defined; code all fits
together and works towards a common objective)
- Isolate areas likely to change
**Identify Design Goals**
Anyone who designs a product needs to start with the goals of that
product.
## Overview
### Software Design
- Describe the contents of a software design
- Explain the enabling techniques (common principles) for design
- Explain common design viewpoints
- Identify different architectural styles and the types of applications
they are appropriate for
- Understand what a software design pattern is and explain the use of the
device, and publish/subscribe patterns
- Describe how to evaluate the quality of a design
- Understand how to perform a design review
- Create uml class, sequence and state diagrams
### Software Construction
- Explain issues in reusing software
- Understand factors that affect software reusability
- Explain the need for software configuration management (SCM)
- Describe the 4 SCM activities
- Describe capabilities of SCM tools
- Define software configuration terminology (CCB, build, release,
configuration item, version)
- Identify benefits of utilizing open source software
- Identify factors to consider in selecting open source components
------
## Software Design
### Lecture 1
In the big picture, we start with system requirements, then system
design, then software requirements, and then software design.
Another term we hear a lot is "software architecture" and "software
architects."
- Create plans/blueprints
- How to solve the customer's requirements and find a way to
conceptualize that that can be implemented by a software engineer
How do you train a (building) architect? What do you teach them?
- _Patterns!_
- Business/economics (understand cost, economics, etc.)
- Constraints (laws, regulations, etc.)
- Quality attributes
_Software architecture_: the structure which comprises the software
elements, externally visible properties of those elements, and the
, relationships among them.
- Software elements: modules, components, entire programs, systems,
services (viewed as "black boxes")
**Architecture Importance**
- Critical to quality of the system (and its assessment)
- Errors are costly (if we create architectural errors, they are very
costly to eventually fix)
- Changes (assess impact of making changes)
- Communication vehicle (stakeholders, development team, integration-test
team, management and customers supporting ideas of estimation, schedule,
cost, and tracking)
**History**
- 1970's: Top-down design; attempt to solve a problem by breaking it into
functions, then subfunctions, etc.; problem decomposition
- 1980's: Data-flow design; in additional to a functional decomp, we were
also taking into account information flow; if we could understand those
flows, maybe we could better optimize those flows
- 1990's: Object-oriented design
- 2000's: services; service-oriented architecture
**Design Principles**
- Iterative: design is iterative; consider it along the lines of doing a
term paper right
- Objective for paper (persuasive? informative?)
- Outline
- Key points
- Key paragraphs
- (Drafting!)
- Finalize
- Traceability: important to trace design aspects to requirements; all
requirements need to be traced to elements of the design
- Reflect problem domain: if we're trying to solve a problem, we would
like to be able to have the design elements map to the problem
domain/system ("conceptual modeling")
- Maintainable
- Do *NOT* contain implementation details: abstract; provide flexibility
- Manage complexity: not to create the most complicated architecture;
keep it simple, stupid
- Minimize coupling (connections between components)
- Maximize cohesion (each elements are well-defined; code all fits
together and works towards a common objective)
- Isolate areas likely to change
**Identify Design Goals**
Anyone who designs a product needs to start with the goals of that
product.
