Analysis and Design Fundamentals

Analysis and Design Fundamentals

• The requirements specification says WHAT our system must do, but not HOW
• There is still quite a large semantic gap between the level of abstraction in the requirements and the level of abstraction in the design. This gap is filled in by performing software analysis.

Structure, Information, and Behavior

• Structure
• identify the modules and specify how they are connected
• Each module will be connected to at least one other module.
• Each module may hold some information.
• In the requirements, we discovered what information is remembered by the system
• In analysis and design, we will allocate the responsibility for storing that information to individual modules
• Behavior
• What the system is able to do
• The largest part of the requirements specification was involved with describing this behavior at the system level.
• In analysis and design we will allocate the functional capabilities to individual modules.

Levels of Development

• Description of the problem to be solved by the software system
• Specify the solution as a requirements specification
• In the requirements, we view the system as a black box
• During analysis, we open the covers of the black box and peer inside.
• Our job is to find the data and functional components inside the system
• The data and functional components that we identify during analysis are discovered rather than invented.
• A technique that is sometimes useful is called noun-verb analysis
• The nouns that appear in the requirements and problem statement indicate the things in the problem.
• The verbs that we use indicate the functions performed by the components inside the system.
• During analysis, after finding the components we model their relationships
• Static relationships show the structure of the solution.
• Dynamic models show what happens when the system is working.
• The requirements show WHAT the structure, information and behavior are for the entire system.
• The analysis identifies WHAT the components inside the system are, WHAT their structural relationships are, and WHAT their information and behavioral properties are.
• Design should be thought of as an abstract model of the code. It describes HOW the code works.
• The beginning of wisdom for a computer programmer is to recognize the difference between getting a program to work and getting it RIGHT.

Structure Modeling

• Most ubiquitous structure in the hierarchy
• If we view a system as being made up of components or modules, it might be useful to organize those components into layers based on their reuse characteristics.
• A more general graph structure is what we might call a network.

Information Modeling

• UML class diagram
• Mathematical models of the data

Behavior Modeling

• Imperative models describe how things happen
• We describe change over time.
• This change is the change in state of the system
• Activity diagram
• Sequence diagram

• Declarative models
• They only specify rules for what will happen in various circumstances
• Decision tables
• State transition diagrams
• Pre and post conditions
• Stepwise refinement

Analysis and Design Principles - Modularity

• Modularity means breaking something complicated into pieces, making things more manageable.
• Abstraction is where we model the essential properties of something that might otherwise be quite complex
• Encapsulation is the separation of information about a module into two parts, a specification, which is an abstraction of what its capabilities are, and an implementation, which hides the details of how it works.
• Module
• as small as a method or function
• as large as a subsystem
• object-oriented systems, the modules are usually classes
• higher level, a package is a collection of related classes
• module specifies a well-defined interface
• high cohesion and low coupling

Analysis and Design Principles - Abstraction

• Abstraction means to highlight the essential properties of something
• The specification answers the WHAT question: What does the module do?
• Specification is an abstraction that makes it easier to understand the module and how to use it.
• Inessential details are suppressed

Analysis and Design Principles - Encapsulation

• Encapsulation is the separation of the specification from the implementation
• Module has these two views: the outside view, or specification, that describes WHAT the module does and how to use it
• The inside view, or implementation, that describes HOW the module does what we say it does.
• Three benefits from encapsulation
• Simple clients
• Internal secrets in the server can be protected
• Modifications to that secret implementation are not visible to the outside