Software Design: An Overview Guy Tremblay and Anne Pons

1
Software Design An OverviewGuy Tremblay and
Anne Pons

• EEL 6883
• Software Engineering Vol. 1 Chapter 4 pp.191-208
• Presenter Sorosh Olamaei

2
1 Introduction

• Design as a life cycle activity bonds the
  requirements to construction
• Process of breaking down the system into
  components, defining interfaces and defining
  components to a level of detail that enables
  their construction
• Blueprint of the solution to be implemented
• Usually not unique

3
Scope of the paper

• DeMarcos terminology
• Decomposition design ( D-design ) mapping of a
  system into its component pieces
• Family Pattern design (FP-Design) goal is to
  establish exploitable commonalities over a family
  of systems
• Not covered User Interface design, Invention
  design (I-design) a conceptualization of a
  system to satisfy discovered needs and
  constraints

4
2 Software Design Concepts

• Design key concepts (car example)
• Goals
• Constraints
• Alternatives
• Representations
• Solutions ( to wicked problems lack of test to
  determine when the problem is indeed solved)

5
2.2 Software Design Context

• Software design is bounded to
• Requirement analysis
• Construction (coding and unit testing)
• Integration and qualification testing
• Linear or Incremental life cycle models

6
2.3 Software Design Process

• Software architectural design
• Software detailed design

7
3 Software Structure and Architecture

• Definition of software architecture
• The fundamental organization of a system
  embodied in its components, their relationships
  to each other, and to the environment, and
  principles guiding its design and evolution.
• Reuse of generic design knowledge
• Architectural Styles
• Design Patterns
• Product Lines

8
3.1 Architectural Structures and Views

• Key purpose of software architecture is
  communication among stakeholders
• Design View
• A collection of models that represent an aspect
  of an entire system.
• Represent a partial aspect of software
  architecture that shows specific properties of a
  software system
• Overall organization of an SDD is composed of a
  number of design views each of which contains a
  subset of the various attributes describing
  design entities
• View model by IEEE
• Decomposition, Dependency, Interface , detailed
  description
• 41 view model by RUP
• Logical, Implementation, Process ,Deployment
  ,Use-case

9
Architectural Structures and Views

• Views can be classified into 3 categories called
  Viewtypes
• Module viewtype
• Component-and-connector viewtype
• Allocation viewtype
• Software architecture is a multifaceted artifact
  produced by the design process and composed of a
  set of relatively independent and orthogonal
  views

10
3.2 Macro/Micro architectural Patterns
Architectural Styles Versus Design Patterns

• A pattern is a common solution to a common
  problem in a given context
• Goal is to codify and document recurring
  solutions to typical problems
• Attributes to ensure transferability
• Pattern name
• The context in which the pattern may apply
• Example illustrating need
• Essence of the general problem
• Underlying solution
• Implementation guidelines
• Related patterns
• Advantages and disadvantages

11
Macro/Micro architectural Patterns Architectural
Styles Versus Design Patterns

• Pattern Classification based on scope and level
  of abstraction
• Architectural Styles
• Design Patterns
• Coding Idioms ( part of software construction not
  explained in this paper)

12
Macro/Micro architectural Patterns Architectural
Styles Versus Design Patterns

• An architectural style expresses a fundamental
  structural organization schema for software
  systems. It provides a rich set of predefined
  subsystems, specifies their responsibilities, and
  includes rules and guideline for organizing the
  relationship between them
• Major Architectural Styles
• General structure
• Distributed systems
• Interactive systems
• Adaptable systems
• Other Styles
• Choice depends on quality attributes that must be
  satisfied. Heterogeneous styles are possible.

13
Macro/Micro architectural Patterns Architectural
Styles Versus Design Patterns

• Gamma et al.
• Creational patterns
• Structural patterns
• Behavioral patterns
• Buschmann et al.
• Structural decomposition patterns
• Organization of work patterns
• Access control patterns
• Management patterns
• Communication patterns

14
3.3 Design of Families of Systems and Frameworks

• Based on software product lines and software
  components
• Software production line A collection of
  systems sharing a managed set of features
  constructed from a common set of core software
  asset
• Building a common set of software assets involves
  identifying the key commonalities encountered
  among the various members of the possible family
  of product- done through domain analysis as well
  as accounting for their possible variability -
  done by identifying and defining reusable and
  customizable components
• In an object-oriented context, a related notion
  is that of framework, a partially complete
  software subsystem that can be extended by
  instantiating specific plug-ins or hot spots

15
4 Software design quality analysis and evaluation

• Software Quality The totality of features and
  characteristics of a software product or service
  that bear on its ability to satisfy stated or
  implied needs
• Properties of Software Quality
• Functionality
• Usability
• Efficiency
• Maintainability
• portability

16
Software design quality analysis and evaluation

• 4.1 Design Quality Attributes
• Run-time qualities
• Development-time qualities
• Impact of architectural choices
• Conceptual integrity which concerns the
  architectures intrinsic quality architecture
  reflects one single set of design ideas leading
  to simplicity, consistency and elegance
• 4.2 Measures (quantitative estimates)
• Depends on selected design approach
• Function-oriented (structured) measures
• Objected-oriented measures
• 4.3 Quality Analysis and Evaluation Tools
• Quality attributes are hard to quantify
• Software design reviews
• Simulation and prototyping

17
5 Software design notations and documentation

• Budgen categorization
• Black-box notation external properties of the
  elements of a design model
• White-box notation describing some aspect of
  the detailed realization of a design element
• Alternative categorization
• Structural/Static properties
• Behavioral/dynamic properties
• 5.1 A selection of Design Notations (UML)
• Class and object diagrams
• Component diagrams
• Deployment diagrams
• Structure charts
• Structure (Jackson) diagrams

18
Software design notations and documentation

• 5.2 Behavioral Descriptions (Dynamic view)
• Activity diagrams
• Interaction diagrams sequence and collaboration
  diagrams
• Data flow diagrams
• State transition diagrams and statechart diagrams
• Pseudo code and program design languages (PDLs)

19
5.2 Design Documentation

• Coherency of the design documentation depends on
  many aspects stakeholders, software development
  methods
• Key practice is selection of an appropriate set
  of views which satisfies different stakeholders
  needs
• Project manager detailed allocation views
• Developer detailed module and component-and-conne
  ctor views

20
Design Documentation

• View documentation also involves describing
  interfaces of the element from that view
• A key characteristic of any interface
  specification must be two-way which means what
  the element provides and what it requires
• Another key idea design should be presented and
  documented in a rational way the rationale
  behind the key decisions should also recorded ex.
  The design alternatives that were considered and
  rejected should be described

21
6 Software Design strategies and methods

• 6.1 General Strategies and Enabling Techniques
• Software design strategies can be described in
  terms of enabling techniques independent of
  specific software development method
• Abstraction
• Coupling and cohesion
• Divide and conquer
• Information hiding and encapsulation
• Sufficiency

22
Software Design strategies and methods

• 6.2 Function-oriented (Structured) Design
• Divide and conquer approach toward identifying
  major system function in a top-down approach.
• Structured analysis produces DFDs of the various
  system functions together with associated process
  descriptions, that is, descriptions of the
  processing performed by each subtask, usually
  using informal Pseudocode.
• Entity-relationship diagrams describing the data
  stores can also be used.
• Key strategies to help derive a software
  architecture from a DFD
• Transaction analysis triggers
• Transformation analysis identifying the central
  transform, structure chart
• Key concept of structured design are those of
  coupling and cohesion restrict coupling to
  normal types data, stamp, control coupling.
  Avoid common and contest coupling

23
Software Design strategies and methods

• Additional Heuristics to improve the quality of
  resulting design
• Fan-in/Fan-out high / low or moderate ( 5-7 max)
• Decision splitting (avoid separating them into
  files)
• Balanced systems top-level modules deal with
  logical and abstract data independent of the
  implementation format

24
Software Design strategies and methods

• 6.3 Object-oriented Design
• Object based (no inheritance or polymorphism) Vs
  object oriented design
• OO design (solution domain) Vs requirement
  analysis ( problem domain)
• Class diagrams Vs Integration diagrams (sequence
  or elaboration diagrams)
• 6.4 Data-structured-oriented Design (Jackson
  Structured Programming)
• Emphasis is on the data that a program
  manipulates rather than the functions it performs
• Motivated by stability in data rather then
  functions that need to be performed
• Restricted to the design of data-processing
  programs using sequential ( batch-style) files
  and processes
• Jackson System Development (JSD) approach
  similar to OOD to address more complex
  interacting processes

25
My views about the paper

• Comprehensive overview which does not get the
  reader lost
• Gets the reader motivated to read the following
  design papers
• Lack of references to sources that expand on
  topics

26

• Questions !?