Software Design: An Software Design: An OverviewOverviewGuy Tremblay and Anne PonsGuy Tremblay and Anne Pons

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

1 Introduction1 Introduction

Design as a life cycle activity bonds Design as a life cycle activity bonds the requirements to constructionthe requirements to construction

Process of breaking down the system Process of breaking down the system into components, defining interfaces into components, defining interfaces and defining components to a level of and defining components to a level of detail that enables their constructiondetail that enables their construction

Blueprint of the solution to be Blueprint of the solution to be implementedimplemented

Usually not unique Usually not unique

Scope of the paperScope of the paper

DeMarco’s terminology:DeMarco’s terminology: Decomposition design ( D-design ): mapping Decomposition design ( D-design ): mapping

of a system into its component piecesof a system into its component pieces Family Pattern design (FP-Design): goal is to Family Pattern design (FP-Design): goal is to

establish exploitable commonalities over a establish exploitable commonalities over a family of systemsfamily of systems

Not covered: User Interface design, Invention Not covered: User Interface design, Invention design (I-design): a conceptualization of a design (I-design): a conceptualization of a system to satisfy discovered needs and system to satisfy discovered needs and constraintsconstraints

2 Software Design 2 Software Design ConceptsConcepts Design key concepts: (car example) Design key concepts: (car example)

– GoalsGoals– ConstraintsConstraints– AlternativesAlternatives– Representations Representations – Solutions ( to wicked problems: lack of test Solutions ( to wicked problems: lack of test

to determine when the problem is indeed to determine when the problem is indeed solved)solved)

2.2 Software Design 2.2 Software Design ContextContext

Software design is bounded to:Software design is bounded to: Requirement analysisRequirement analysis Construction (coding and unit Construction (coding and unit

testing) testing) Integration and qualification Integration and qualification

testingtesting Linear or Incremental life cycle Linear or Incremental life cycle

modelsmodels

2.3 Software Design 2.3 Software Design ProcessProcess Software architectural designSoftware architectural design Software detailed designSoftware detailed design

3 Software Structure 3 Software Structure and Architectureand Architecture

Definition of software architecture:Definition of software architecture: The fundamental organization of a system embodied in its The fundamental organization of a system embodied in its

components, their relationships to each other, and to the components, their relationships to each other, and to the environment, and principles guiding its design and evolution.environment, and principles guiding its design and evolution.

Reuse of generic design knowledge:Reuse of generic design knowledge: Architectural Styles Architectural Styles Design PatternsDesign Patterns Product Lines Product Lines

3.1 Architectural 3.1 Architectural Structures and ViewsStructures and Views Key purpose of software architecture is Key purpose of software architecture is

communication among stakeholderscommunication among stakeholders Design View: Design View:

– A collection of models that represent an aspect of an A collection of models that represent an aspect of an entire system. entire system.

– Represent a partial aspect of software architecture that Represent a partial aspect of software architecture that shows specific properties of a software systemshows specific properties of a software system

– Overall organization of an SDD is composed of a number Overall organization of an SDD is composed of a number of design views each of which contains a subset of the of design views each of which contains a subset of the various attributes describing design entitiesvarious attributes describing design entities

View model by IEEE:View model by IEEE:

– Decomposition, Dependency, Interface , detailed Decomposition, Dependency, Interface , detailed descriptiondescription

4+1 view model by RUP:4+1 view model by RUP:– Logical, Implementation, Process ,Deployment ,Use-caseLogical, Implementation, Process ,Deployment ,Use-case

Architectural Architectural Structures and ViewsStructures and Views Views can be classified into 3 Views can be classified into 3

categories called Viewtypes:categories called Viewtypes:– Module viewtype Module viewtype – Component-and-connector viewtypeComponent-and-connector viewtype– Allocation viewtypeAllocation viewtype

Software architecture is a multifaceted Software architecture is a multifaceted artifact produced by the design process artifact produced by the design process and composed of a set of relatively and composed of a set of relatively independent and orthogonal views independent and orthogonal views

3.2 3.2 Macro/Micro architectural Patterns: Macro/Micro architectural Patterns: Architectural Styles Versus Design Architectural Styles Versus Design PatternsPatterns

A pattern is a common solution to a common problem A pattern is a common solution to a common problem in a given contextin a given context

Goal is to codify and document recurring solutions to Goal is to codify and document recurring solutions to typical problemstypical problems

Attributes to ensure transferability: Attributes to ensure transferability: – Pattern name Pattern name – The context in which the pattern may applyThe context in which the pattern may apply– Example illustrating needExample illustrating need– Essence of the general problemEssence of the general problem– Underlying solution Underlying solution – Implementation guidelines Implementation guidelines – Related patternsRelated patterns– Advantages and disadvantagesAdvantages and disadvantages

Macro/Micro architectural Patterns: Macro/Micro architectural Patterns: Architectural Styles Versus Design Architectural Styles Versus Design PatternsPatterns

Pattern Classification based on scope Pattern Classification based on scope and level of abstraction:and level of abstraction:– Architectural StylesArchitectural Styles– Design PatternsDesign Patterns– Coding Idioms Coding Idioms ( part of software construction not ( part of software construction not

explained in this paper)explained in this paper)

Macro/Micro architectural Patterns: Architectural Macro/Micro architectural Patterns: Architectural Styles Versus Design PatternsStyles Versus Design Patterns

An architectural style expresses a An architectural style expresses a fundamental structural organization schema fundamental structural organization schema for software systems. It provides a rich set of for software systems. It provides a rich set of predefined subsystems, specifies their predefined subsystems, specifies their responsibilities, and includes rules and responsibilities, and includes rules and guideline for organizing the relationship guideline for organizing the relationship between thembetween them

Major Architectural Styles:Major Architectural Styles:– General structureGeneral structure– Distributed systemsDistributed systems– Interactive systemsInteractive systems– Adaptable systemsAdaptable systems– Other StylesOther Styles

Choice depends on quality attributes that must be satisfied. Choice depends on quality attributes that must be satisfied. Heterogeneous styles are possible.Heterogeneous styles are possible.

Macro/Micro architectural Patterns: Architectural Macro/Micro architectural Patterns: Architectural Styles Versus Design PatternsStyles Versus Design Patterns

Gamma et al. :Gamma et al. :– Creational patternsCreational patterns– Structural patternsStructural patterns– Behavioral patternsBehavioral patterns

Buschmann et al. :Buschmann et al. :– Structural decomposition patternsStructural decomposition patterns– Organization of work patternsOrganization of work patterns– Access control patternsAccess control patterns– Management patternsManagement patterns– Communication patternsCommunication patterns

3.3 Design of Families 3.3 Design of Families of Systems and of Systems and FrameworksFrameworks Based on software product lines and software Based on software product lines and software

componentscomponents Software production line : A collection of systems Software production line : A collection of systems

sharing a managed set of features constructed from a sharing a managed set of features constructed from a common set of core software assetcommon set of core software asset

Building a common set of software assets involves Building a common set of software assets involves identifying the key commonalities encountered among identifying the key commonalities encountered among the various members of the possible family of product- the various members of the possible family of product- done through domain analysis as well as accounting done through domain analysis as well as accounting for their possible variability - done by identifying and for their possible variability - done by identifying and defining reusable and customizable components defining reusable and customizable components

In an object-oriented context, a related notion is that In an object-oriented context, a related notion is that of framework, a partially complete software of framework, a partially complete software subsystem that can be extended by instantiating subsystem that can be extended by instantiating specific plug-ins or hot spotsspecific plug-ins or hot spots

4 Software design 4 Software design quality analysis and quality analysis and evaluationevaluation Software Quality: The totality of features Software Quality: The totality of features

and characteristics of a software product and characteristics of a software product or service that bear on its ability to or service that bear on its ability to satisfy stated or implied needssatisfy stated or implied needs

Properties of Software QualityProperties of Software Quality– Functionality Functionality – UsabilityUsability– EfficiencyEfficiency– Maintainability Maintainability – portabilityportability

Software design Software design quality analysis and quality analysis and evaluationevaluation 4.1 Design Quality Attributes4.1 Design Quality Attributes

Run-time qualitiesRun-time qualities Development-time qualitiesDevelopment-time qualities

– Impact of architectural choices Impact of architectural choices – Conceptual integrity which concerns the architecture’s Conceptual integrity which concerns the architecture’s

intrinsic quality : architecture reflects one single set of intrinsic quality : architecture reflects one single set of design ideas leading to simplicity, consistency and design ideas leading to simplicity, consistency and eleganceelegance

4.2 Measures (quantitative estimates)4.2 Measures (quantitative estimates)– Depends on selected design approachDepends on selected design approach

Function-oriented (structured) measuresFunction-oriented (structured) measures Objected-oriented measuresObjected-oriented measures

4.3 Quality Analysis and Evaluation Tools 4.3 Quality Analysis and Evaluation Tools – Quality attributes are hard to quantifyQuality attributes are hard to quantify

Software design reviewsSoftware design reviews Simulation and prototypingSimulation and prototyping

5 Software design 5 Software design notations and notations and documentationdocumentation

– Budgen categorization:Budgen categorization: Black-box notation : external properties of the Black-box notation : external properties of the

elements of a design modelelements of a design model White-box notation : describing some aspect of White-box notation : describing some aspect of

the detailed realization of a design elementthe detailed realization of a design element

– Alternative categorization:Alternative categorization: Structural/Static propertiesStructural/Static properties Behavioral/dynamic propertiesBehavioral/dynamic properties

– 5.1 A selection of Design Notations (UML)5.1 A selection of Design Notations (UML) Class and object diagramsClass and object diagrams Component diagramsComponent diagrams Deployment diagramsDeployment diagrams Structure chartsStructure charts Structure (Jackson) diagramsStructure (Jackson) diagrams

Software design Software design notations and notations and documentationdocumentation

– 5.2 Behavioral Descriptions 5.2 Behavioral Descriptions (Dynamic view)(Dynamic view) Activity diagramsActivity diagrams Interaction diagrams : sequence and Interaction diagrams : sequence and

collaboration diagramscollaboration diagrams Data flow diagramsData flow diagrams State transition diagrams and State transition diagrams and statechart statechart

diagramsdiagrams Pseudo code and program design Pseudo code and program design

languages (PDLs)languages (PDLs)

5.2 Design 5.2 Design DocumentationDocumentation Coherency of the design documentation Coherency of the design documentation

depends on many aspects: depends on many aspects: stakeholders, software development stakeholders, software development methods …methods …

Key practice is selection of an Key practice is selection of an appropriate set of views which satisfies appropriate set of views which satisfies different stakeholders needsdifferent stakeholders needs– Project manager: detailed allocation viewsProject manager: detailed allocation views– Developer: detailed module and component-Developer: detailed module and component-

and-connector viewsand-connector views

Design DocumentationDesign Documentation

View documentation also involves describing View documentation also involves describing interfaces of the element from that viewinterfaces of the element from that view

A key characteristic of any interface A key characteristic of any interface specification : must be two-way which means specification : must be two-way which means what the element provides and what it requireswhat the element provides and what it requires

Another key idea: design should be presented Another key idea: design should be presented and documented in a rational way: the and documented in a rational way: the rationale behind the key decisions should also rationale behind the key decisions should also recorded ex. The design alternatives that were recorded ex. The design alternatives that were considered and rejected should be describedconsidered and rejected should be described

6 Software Design 6 Software Design strategies and strategies and methodsmethods 6.1 General Strategies and Enabling 6.1 General Strategies and Enabling

TechniquesTechniques– Software design strategies can be described Software design strategies can be described

in terms of enabling techniques : in terms of enabling techniques : independent of specific software independent of specific software development methoddevelopment method

AbstractionAbstraction Coupling and cohesionCoupling and cohesion Divide and conquerDivide and conquer Information hiding and encapsulationInformation hiding and encapsulation SufficiencySufficiency

Software Design Software Design strategies and strategies and methodsmethods 6.2 Function-oriented (Structured) Design6.2 Function-oriented (Structured) Design

Divide and conquer approach toward identifying major Divide and conquer approach toward identifying major system function in a top-down approach.system function in a top-down approach.

Structured analysis produces DFDs of the various system Structured analysis produces DFDs of the various system functions together with associated process descriptions, functions together with associated process descriptions, that is, descriptions of the processing performed by each that is, descriptions of the processing performed by each subtask, usually using informal Pseudocode.subtask, usually using informal Pseudocode.

Entity-relationship diagrams describing the data stores can Entity-relationship diagrams describing the data stores can also be used.also be used.

– Key strategies to help derive a software architecture from Key strategies to help derive a software architecture from a DFDa DFD

Transaction analysis: triggersTransaction analysis: triggers Transformation analysis : identifying the central transform, Transformation analysis : identifying the central transform,

structure chartstructure chart– Key concept of structured design are those of coupling and Key concept of structured design are those of coupling and

cohesion: restrict coupling to normal types: data, stamp, cohesion: restrict coupling to normal types: data, stamp, control coupling. Avoid control coupling. Avoid commoncommon and and contestcontest coupling coupling

Software Design Software Design strategies and strategies and methodsmethods

– Additional Heuristics to improve the Additional Heuristics to improve the quality of resulting designquality of resulting design Fan-in/Fan-out: high / low or moderate Fan-in/Fan-out: high / low or moderate

( 5-7 max)( 5-7 max) Decision splitting (avoid separating Decision splitting (avoid separating

them into files)them into files) Balanced systems: top-level modules Balanced systems: top-level modules

deal with logical and abstract data deal with logical and abstract data independent of the implementation independent of the implementation formatformat

Software Design Software Design strategies and strategies and methodsmethods 6.3 Object-oriented Design6.3 Object-oriented Design

– Object based (no inheritance or polymorphism) Vs object Object based (no inheritance or polymorphism) Vs object oriented designoriented design

– OO design (solution domain) Vs requirement analysis OO design (solution domain) Vs requirement analysis ( problem domain)( problem domain)

– Class diagrams Vs Integration diagrams (sequence or Class diagrams Vs Integration diagrams (sequence or elaboration diagrams)elaboration diagrams)

6.4 Data-structured-oriented Design (Jackson Structured 6.4 Data-structured-oriented Design (Jackson Structured Programming)Programming)– Emphasis is on the data that a program manipulates Emphasis is on the data that a program manipulates

rather than the functions it performsrather than the functions it performs– Motivated by stability in data rather then functions that Motivated by stability in data rather then functions that

need to be performedneed to be performed– Restricted to the design of data-processing programs Restricted to the design of data-processing programs

using sequential ( batch-style) files and processesusing sequential ( batch-style) files and processes– Jackson System Development (JSD) : approach similar to Jackson System Development (JSD) : approach similar to

OOD to address more complex interacting processesOOD to address more complex interacting processes

My views about the My views about the paperpaper Comprehensive overview which Comprehensive overview which

does not get the reader lost does not get the reader lost Gets the reader motivated to read Gets the reader motivated to read

the following design papersthe following design papers Lack of references to sources that Lack of references to sources that

expand on topicsexpand on topics

Questions !?Questions !?