Introduction to software design & architecture

Jetzt loslegen. Gratis!
oder registrieren mit Ihrer E-Mail-Adresse
Introduction to software design & architecture von Mind Map: Introduction to software design & architecture

1. Software Engineering

1.1. The application of engineering to build software

2. Engineering problem solving approach

2.1. functional fixedness limits our ability to find design solutions.

2.2. holistic problem solving framework

2.2.1. initial state

2.2.1.1. interpret the problem & evaluate the constraints

2.2.2. operational state

2.2.2.1. brainstorming, finding possibilities and evaluating solutions

2.2.3. goal state

2.2.3.1. implementing the best solution

2.3. Problem solving skills are important in sw design

3. Sofware Design Princples

3.1. Modularization

3.1.1. decomposition of software until fine components are created

3.1.2. isolate errors, reduce redundancies and keep software manageable.

3.2. Abstraction

3.2.1. provide the essential characteristics of entities

3.2.2. Functional Abstraction

3.2.2.1. gives reasoning behind behavioral operations

3.2.3. Data Abstraction

3.2.3.1. gives reasoning about structural composition of data objects

3.2.4. hides details making system easier to use, gives overall solution and postpone details

3.3. Encapsulation

3.3.1. provide access only to necessary data of abstracted entities

3.4. Coupling

3.4.1. measure of interdependence between modules

3.4.2. common coupling

3.4.2.1. modules has common access area

3.4.3. content coupling

3.4.3.1. modules modify and rely on other modules

3.4.4. external coupling

3.4.4.1. modules share externally imposed data

3.4.5. control coupling

3.4.5.1. one module control flow of another module

3.4.6. stamp coupling

3.4.6.1. when modules share a composite of data structure and share only parts of it

3.4.7. Data coupling

3.4.7.1. when modules share data through parameters

3.5. Cohesion

3.5.1. the degree to which module tasks are related to each other

3.5.2. functional cohesion

3.5.2.1. tasks work to perform one function

3.5.3. procedural cohesion

3.5.3.1. in steps get the unit purpose

3.5.4. temporal cohesion

3.5.4.1. performed at a specific time

3.5.5. communication cohesion

3.5.5.1. consume same data

3.6. Separation of interface and implementation

3.7. Completeness

3.7.1. no less

3.8. Sufficiency

3.8.1. no more

4. Software Engineering Design

4.1. Process

4.1.1. activities required to model software structure and behavior

4.1.2. concerned with project management

4.2. Product

4.2.1. artifacts resulting from design activities

4.2.2. concerned with technical aspects

4.3. Importance

4.3.1. Design forms the foundations to all development activities

4.4. Challenges

4.4.1. Requirements volitality

4.4.2. Inconsistent development processes

4.4.3. Technology

4.4.4. Managing design influences

4.4.5. The ethics

5. Software Design Process

5.1. Major activities

5.1.1. Software Architecture

5.1.1.1. Provide the major structural components of the system, and serve as an analysis tool

5.1.1.2. focus on non-functional requirements

5.1.1.3. BLACK-BOX MODELS

5.1.2. Detailed design

5.1.2.1. Refine the architecture and focus on the internals

5.1.2.2. Component Design & interface Design

5.1.2.3. focus on functional requirements

5.1.2.4. WHITE-BOX MODELS

5.2. Other activities

5.2.1. Design documentation

5.2.1.1. pivot rule in system development and maintenance

5.2.1.2. through out the lifetime of software system

5.2.2. Design management

5.2.2.1. activities to effeciently create quality design artifacts within schedule and budget

5.2.2.2. Quality is the focal point

6. Roles of software designers

6.1. Systems Engineer: design the overall process of a whole system

6.2. Software architect: design systems using black-box modeling

6.3. Component designer: have strong programming skills

6.4. User interface designer: looks for usability

7. Design stratigies

7.1. OO Design strategy: appropriate for OO language

7.2. Functional Design strategy: inappropriate for OO

8. Design consedirations

8.1. we should minimize complexity to support changes in later stages