Software Design: An Overview Guy Tremblay and Anne Pons - PowerPoint PPT Presentation


PPT – Software Design: An Overview Guy Tremblay and Anne Pons PowerPoint presentation | free to download - id: 64bd67-MmVjN


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Software Design: An Overview Guy Tremblay and Anne Pons


Software Design: An Overview Guy Tremblay and Anne Pons EEL 6883 Software Engineering Vol. 1 Chapter 4 pp.191-208 Presenter: Sorosh Olamaei 1 Introduction Design as a ... – PowerPoint PPT presentation

Number of Views:26
Avg rating:3.0/5.0
Date added: 12 May 2020
Slides: 27
Provided by: eecsUcfE7
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Design: An Overview Guy Tremblay and Anne Pons

Software Design An OverviewGuy Tremblay and
Anne Pons
  • EEL 6883
  • Software Engineering Vol. 1 Chapter 4 pp.191-208
  • Presenter Sorosh Olamaei

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

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

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)

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

2.3 Software Design Process
  • Software architectural design
  • Software detailed design

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

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
  • 41 view model by RUP
  • Logical, Implementation, Process ,Deployment

Architectural Structures and Views
  • Views can be classified into 3 categories called
  • 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

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

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)

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.

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

3.3 Design of Families of Systems and Frameworks
  • Based on software product lines and software
  • Software production line A collection of
    systems sharing a managed set of features
    constructed from a common set of core software
  • 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

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

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

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

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

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

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

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

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

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
  • Balanced systems top-level modules deal with
    logical and abstract data independent of the
    implementation format

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

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

  • Questions !?