Software Engineering Design Resolution

• At the end of Design Analysis, requirements and system are viewed as a black box with external behavior and characteristics, with initial potential internals explored through class diagrams
• Software Engineering Design Resolution aims to develop a design solution for the problem stated in the requirements
• Design Resolution consists of Architectural and Detailed Design
• The result is a design document from which code implementation can proceed

Design Levels

• Architectural design defines major components, their high-level structure (responsibilities, properties, interfaces), and their relationships and interactions
• Detailed design defines and "opens" the internal elements of major components, their structures, relationships, interactions, processing algorithms, and attribute (data) structures

Main Parts of Software Architecture

• Decomposition/Composition of main components
• Assignment of responsibilities/functionalities to those components
• Specification of properties, including states and transitions
• Specification of relationships, including collaboration and interfaces

Architectural Design Considerations (DeSCRIPTR)

• Decomposed system into major components
• States that the major components may exist in
• Collaboration among components
• Relationships among the major components in terms of dependencies and communications
• Interfaces among the components that have relationships
• Properties that the major components must possess or satisfy
• Transitions of components' states
• Responsibilities of the major components
• Architectural Design may contain all or parts of this list.

Detailed Design Considerations

• Detailed Design is a refinement of Architecture Design, starting with detailed decomposition of major components and subsequent refinements with smaller elements
• Refined DeSCRIPTR is part of detailed design
• Packaging of components and related elements
• Implementation specifications for the packaged components
• Algorithms to implement services/functionalities
• Data structures and data types

Basic Design Principles

• Design Principles improve design, sharing similarities with other disciplines but some are specific to SE
• Basic Design Principles improve satisfying product specification
• Feasibility: Design can be technically implemented
• Adequacy: Meets stakeholders' needs and expectations
• Economy: Can be implemented within reasonable cost (resource and time)
• Changeability: System is easily modifiable

Observations About Basic Principles

• Feasibility may require time to assess
• Adequacy may not be binary
• Economy has easy and difficult parts to assess
• Changeability can be measured with modular size, documentation, external interfaces, and use of abstract classes and inheritance

Design Criteria

• Constructive (Construction) Design Principles lead to a good quality product and satisfy Basic Design Principles
• Modularity: modules with well-defined interfaces lead to high quality
• Implementability: easier to implement lead to high quality
• Aesthetic: beauty and ease of use please users.

Modularity in Design

• Construct the design via decomposition and reconstruction in the form of well-defined, independent modules/units that perform clear services and have clear interfaces
• A module may be a Class
• Definition is not clear, can be based on size or complexity
• Advantages of modular design include ease of understanding, documentation, change, test, reuse, and performance improvement

Modularity Principles

• Principle of Small Modules: Design with smaller ones -Physical size and mental states
• Principle of Information Hiding: shields internal details of a Module's Structure and Processing -Clearly defined interfaces
• Principle of Least Privilege: Doesn't allow access to unneeded resources -Restricts modules from accessing unneeded resources

Low Coupling and High Cohesion

• Coupling reflects the degree of relatedness among modules which should be kept to a minimum
• Cohesion is the degree of relatedness of parts within a module which should be maximized

Levels of Coupling

• Content: worst, high coupling (module directly references content of another)
• Common: modules use common "global" data
• Control: module passes information to control logic of another
• Stamp: module passing complete structure to another
• Data: best, low coupling (only necessary items passed)

Levels of Cohesion

• Coincidental: worst, weakest (module performs unrelated tasks)
• Logical: module performs series of related functionalities
• Temporal: module tasks related in time
• Procedural: module performs related procedures that should be done separately
• Communicational: module tasks on same data where sequence is based on a procedure
• Sequential: module performing related tasks where output of one is the input to the next
• Functional: best, strongest (module performs one task to achieve a singlegoal)

Balancing the Design

• Design small, single-purpose, cohesive modules which causes a lot of data being passed.
• Designers should balance low coupling and high cohesion
• Low coupling and high cohesion can improve: understandability, documentation, changeability, ease of testing and debugging, re-usability, and improvement

Implementability Principles

• After having an implementable design, designers address how easy it is to implement.
• Simple designs are often the easiest to understand and implement with the least steps
• Reuse existing artifacts
• Design with re-use

Aesthetic Principles

• Gelernter of Yale states that beauty is simplicity and powerful functionality
• User-Oriented Design deligths users and matches/exceeds their expectations

Other Principles

• Design to "delight" the users by matching or exceeding expectations and staying within users' knowledge and experience contexts
• Design to "improve the user experience" by matching users' past experience and extending the experience by extrapolating and improving some part of the interaction