4 design Concepts

• What is design concepts ?

  A combo of creativity, requirements, and technical considerations that form a product or system

  Design creates model of software architecture, data structures, interfaces, and components that are necessary to implement the system.
• Software Design

  • Set of principles, concepts, and practices that help develop a high quality system or product
  • Design principles establish a philosophy that guides the designer as the work is performed
  • Design concepts must be understood before the mechanics of design practice are applied
  • Software design practices change continuously as new methods, better analysis, and broader understanding evolve.
• Software Engineering Design

  1. Data/Class: transforms analysis classes into implementation classes and data structures
  2. Architectural design: defines relationships among the major software structural elements
  3. Interface: how software elements, hardware elements, and end-users communicate.
  4. Component-level: transforms structural elements into procedural descriptions of software components.
• Quality Guidelines

  1. have architecture (a) created using recognizable styles or patterns, (b) made of well designed components (c) implemented in evolutionary way
  2. be modular
  3. contain representations of data, architecture, interfaces, and components.
  4. lead to data structures drawn from recognized data patterns
  5. contain functionally independent components
  6. lead to interfaces that simplify connections between components and external environment.
  7. be derived using a repeatable method that is driven by software requirements analysis.
  8. be represented using meaningful notation.
• Common Design Characteristics

  1. A way of translating requirements model into design representation
  2. A notation for representing functional components and their interfaces
  3. Heuristics for refinement and partitioning
  4. Guidelines for quality assessment
• Design Concepts: Abstraction

  data: named collection of data describing data object

  procedural: name sequence of instructions with specific and limited function

  Hight level: solution uses the language of the problem

  Lower level: more detailed description of the solution. Problem-oriented terminology is coupled with implementation oriented terminology to state a solution.

  Lowest level: solution is a way that can be directly implemented
• Design Concepts: Architecture

  structure or organization of software components

  ways components interact

  structure of data used by components
• Design Concepts: Design Patterns

  • describe a design structure that solves a well- defined design problem in a specific context.
• Design Concept: Separation of Concerns

  • any complex problem can be more easily handled if it is subdivided into piece
  • concern: a feature/behavior that is specified as part of the requirements model for the software
  • problem takes less time and effort to solve
• Design Concepts: Modularity

  • Compartmentalization of data and function
  • Monolithic software: a large program composed of a single module. Can not be easily grasped by a software engineer
• Design Concepts: Information Hiding

  • controlled interfaces which define and enforce access to component procedural detail and any local data structure used by the component.
  • reduce side effects
  • limit global impact of local design decisions
  • communication through controlled interfaces
  • avoid global data
  • leads to encapsulation
  • high quality software
• Design Concept: Functional independence

  • single-minded (high cohesion) components with aversion to excessive interaction with other components (low coupling).
• Design Concept: Stepwise Refinement

  • incremental elaboration of detail for all abstractions.
  • Top down
  • Abstraction and refinement are complementary concepts.Abstraction lets you specify procedure and data internally but suppress the need for “outsiders” to have knowledge of low-level details.

  Refinement helps you reveal low-level details as design progresses.

  Abstraction allows you to define how things work and the information they hold internally, while hiding the intricate details from external users.
• Design Concept: Refactoring

  • a reorganization technique that simplifies the design without changing it's function
  • Look for this when refactoring:
  • redundancy
  • unused design
  • inefficient / unnecessary algorithms
  • poor or inappropriate data structures
  • any design failure that can be corrected to get a better design
• Design Concept: Design Classes

  • provide design detail that allow analysis classes to be implemented.
• Architecture Properties

  1. Structural properties: defines the components of a system (modules, objects, filters) and how they're packaged and interact with one another.
  2. Extra-functional properties: should address how the design architecture achieves non-functionals requirements (capacity, reliability, security, adaptability).
  3. Families of related systems: should use repeatable patterns (building blocks) encountered in designing similar systems
• Design Patterns

  a description of a common way to solve a particular software problem
• Coupling Minimization

  • Failure to hide information = tight coupling.
  • Tight coupling happens when a module can access details of another module.
  • Avoid tight coupling
  • Modules that communicate by a global variable, file, class are tightly coupled.
  • Modules that communicate by data types or structures are more tightly coupled than modules that pass standard data values.
  • Avoid Special data types or structures
  • When modules communicate only through public interfaces, their coupling strength is proportional to the number of messages and the amount of data passed between them
• Cohesion Minimization

  • Cohesion is highest in modules that have a single clear, logically independent responsibility or role.
  • One practice to have cohesion is to form modules that implement data types.
  • Build a module hierarchy reflecting the levels of abstraction in a program.
  • If the module hierarchy reflects the levels of abstraction in a program, then cohesive modules should not have parts that cross levels of abstraction.
• Design Class Characteristics

  • Complete: includes all necessary attributes and methods
  • sufficient: contains only the methods needed to achieve class intent
  • Primitiveness: each class method focuses on providing one service
  • High cohesion: small, focused, single-minded classes.
  • Low coupling: Min class collaboration
• Design Modeling Principles

  1. Should be traceable to the requirements model.
  2. Always consider the architecture of the system to be built
  3. Data design is as important as design of processing functions.
  4. Design Interfaces with care.
  5. User interface design should be tuned to the needs of the end user and stress ease of use.
  6. Component-level design should be functionally independent.
  7. Components should be loosely coupled to each other and the environment
  8. models should be easy to understand
  9. Develop design iteratively
  10. Creation of a design model does not preclude using an agile approach
• Data model: data objects and database architectures

  • Examines data objects independent of processing
  • Focuses attention on the data domain
  • Creates a model at the customer’s level of abstraction
  • Indicates how data objects relate to one another
• Data object: can be an external entity, thing, event, place, role, organizational unit, or a structure

  • contain a set of attributes that act like a quality, characteristic, or descriptor of the object.
  • Data objects may be connected to one another in many different ways.
• Architectural Design Elements

  • like the floor plan for a house
  • architectural model comes from three sources:
  • Information about the application domain for the software to be built
  • Specific requirements model elements such as data flow analysis classes and their relationships (collaborations) for the problem
  • Availability of architectural patterns and styles
• Interface Design Elements

  • UI: user interface
  • External interfaces to other elements
  • Internal/external interfaces between other design parts
  • UX: user experience
  • UI/UX is a major engineering action to ensure creating usable software products.
  • Internal and external interfaces should have error checking and security features
• Component-Level Design Elements

  • Describes the internal detail of each software component
  • Defines: Data structures for all local data objects, Algorithm detail for all functions that process components, Interface that allows access to component operations
  • Modeled using UML component diagrams
• Deployment Design Elements

  • Show how software functionality and subsystems will be assigned in the physical computing environment.
  • Modeled using UML deployment diagrams
  • Descriptor Form Deployment Diagrams: show computing environment but not configuration details
  • Instance Form Deployment Diagrams: identify hardware configurations and are developed in later design stages