Components Based Design and Development
Computer Engineering Studies
Universidad Carlos III de Madrid
Unit 3: Software Design Quick Overview
Juan Llorens
Högskolan på Åland – Finland / Universidad Carlos III de Madrid - Spain
[Link]@[Link]
Juan Llorens - Software Design Overview 1
Where is the Software Design activity located
Requirements System
System Development Process
definition decommissioning
System System
design evolution
For Software subsystems Sub-system System
development installation
System
integration
Workflows Phases of the life cycle
Requirements Phase 1 Phase 2 Phase 3 Phase n
Capture
Analysis
Design Software Design: Architectural and Detailed Design
Implementation
Testing
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
Juan Llorens - Software Design Overview 2
Transition from Analysis to Design
Workflows Phases of the life cycle
Phase 1 Phase 2 Phase 3 Phase n specification
requirements
WHAT : PROBLEM
analysis
Analysis
design HOW : SOLUTION
implementation
tests Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1
iterations
Juan Llorens - Software Design Overview 3
Transition from Analysis to Design (II)
• The Analysis activity pretends to model an understanding of the system to be
developed => [Application] Problem Domain
• The Design activity pretends to model a possible solution to a particular
[Application] problem => [Application] Solution Domain
• Grey Zone : Where is the border between both activities?
Juan Llorens - Software Design Overview 4
Transition from analysis to Design : Example
1. Requirements 2. Requirements Analysis 3. Grey Zone
Capture
Statics Dynamics
“Cars should be able to Bridge
travel from the top of Smith Auto
Hill at 65 mph, travel in a Distance =
straight line, and arrive at
Road Speed*Time Could be a problem understanding
Jones Hollow within 3
minutes.” or a solution decision
(added for Support use case
detailed Auto 4. Architecture
design) Guardrail Cable Cable
5. Detailed Road
Design
Smith Pylon
Hill Pylon
Based on E. Braude, Software Engineering: An Object-Oriented Perspective
Juan Llorens - Software Design Overview 5
Software design
• The process of converting the system specification into computational model
ready to be coded.
• Software design
– Design a software structure that realises the specification;
• And.. Implementation
– Translate this structure into an executable program;
• The activities of design and implementation are closely related and may be
inter-leaved.
Based on Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 4
Juan Llorens - Software Design Overview 6
So0 What is Software Design
• To develop Computational Models representing a complete Solution to a
proposed software need (Problem).
– Design implies to find computational solutions to problems representing functional
and not functional needs
– Design implies to perform Modeling
Design => Solve problems using models
Juan Llorens - Software Design Overview 7
What are the design instruments?
• 1- A Process guidance
– A Design process defining what activities to follow
• 2- Techniques
– 2.1 High Level: Problem solving techniques
– 2.2 Low Level: Modeling techniques
• 3- Rules
– Constraints applied to system models;
• 4- Tools
– Whatever conceptual device that can be applied to solve a particular problem
• 5- Recommendations
– Advice on good design practice;
• 6- Documentation guidelines
– Based on document templates
Based on Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 1
Juan Llorens - Software Design Overview 8
1- Design process model: process activities
• A general process model for Components Based Development (CBD):
– Architectural design : The overall organization of the system
– Abstract specification : The problem formal specification
– Interface design : The definition of communications
– [Detailed] Components design : The definition of components
– Data structure design : The definition of information
– Algorithm design : The definition of behaviour
Based on Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 4
Juan Llorens - Software Design Overview 9
Sommerville’s software design process
Requirements
specification
Design activities
Data
Architectural Abstract Interface Component Algorithm
structure
design specification design design design
design
• Architectural design: Identify sub-systems.
• Abstract specification: Specify sub-systems.
• Interface design: Describe sub-system interfaces.
• Component design: Decompose sub-systems
into components.
• Data structure design: Design data structures to hold problem data.
• Algorithm design: Design algorithms for problem functions.
©Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 4
Juan Llorens - Software Design Overview 10
2.1- Problem Solving techniques for Software Design
• Apply existing design solutions to already solved design problems that occur
in my project
• Be able to find and Reuse previous designs (solutions) for the problems of
my project
• Build in advance general solutions to be applied to my present and future
problems
• If nothing from the previous help => model a solution form scratch
Based on Ian Sommerville 2004 - Software Engineering, 7th edition. Chapter 1
Juan Llorens - Software Design Overview 11
2.2 - Modeling: Analogy with architecture (for buildings)
• Does it make sense to lay the bricks before making the plans?
• the model - the plans help to master the complexity of the project
• What is the language adequate for representing the plans?
• Direct engineering and reverse engineering: a house, a car, a virus...
Direct
engineering
reverse
engineering
Juan Llorens - Software Design Overview 12
What is a model?
• Abstraction or simplification of the reality: divide and conquer
• Various types of models:
– structure, electricity, sanitation, Q
– static, dynamic...
how are they related between themselves?
• Formal models and informal models
– Informal models: ad hoc, without a common language
– Formal models: universal language, precision, rigor, coherence
• Modelling and language
– language is a vehicle for your thoughts: helps to think clearly
– modelling is an essential element of the process of software development
– modelling requires an adequate language
• To model is not (just) to make diagrams but to think with diagrams
Juan Llorens - Software Design Overview 13
System, model, diagram
• a system is a collection of elements organized to fulfil a concrete finality
– a system can be divided into subsystems
• a model is an abstraction of a system, a simplification (complete and
consistent) of the real system, which is used to better understand it
– Temporarily, a model may be incomplete (missing elements) or inconsistent
(containing contradictions)
– a system can be modelled from different complementary viewpoints, according to
what is considered relevant in each case
• a diagram is the graphical representation of a set of interconnected elements,
a partial view of a model
– a model is not just a collection of diagrams
– a model may contain elements not represented in a diagram
– a model may contain textual specifications which are essential
Juan Llorens - Software Design Overview 14
Analysis models and design models
• Essential parts of the documentation of any project
• Despite the use of a similar notation, the models of analysis and design are
abstractions (models) of different things
– analysis (conceptual model): abstraction of the problem, the real world as it is,
or will be, in which the proposed system will be built
– design (model of the software): abstraction of the internal construction of the
proposed system, rather than the solution to the problem posed in the real world
• Therefore, they have a different purpose
– problem: to study the requirements without making decisions of implementation
– solution: to establish how to build the system before actually building it
• There is no strict temporal ordering between analysis and design
– Analysis precedes design but only within an iteration
– They are interdependent models; they can evolve in parallel
• Transition is neither simple, immediate nor automatic (problem solution)
– A good design is not attained simply by “adding details” to the analysis
– the analysis model cannot be transformed simply in a part of the design model:
they represent different realities
Juan Llorens - Software Design Overview 15
Analysis and design represent different realities
Domain of the Domain of the
problem solution
Design model
Analysis model
Abstraction (model of the
(conceptual model)
software)
Problem in the real Implementation of
world the (SW) solution
Reality
(reality external to the (software internal to
system) the system)
H. Kaindl. “Difficulties in the Transition from OO Analysis to Design”. IEEE Software, 16(5), 1999.
Juan Llorens - Software Design Overview 16
Differences between the models of analysis and design
• analysis: creation of a specification of the problem and of the requirements
– Exploration and clarification of the requirements on the system
– construction of a model of the real world based on the concepts of the domain
(conceptual model)
– What must (or does: reverse engineering) the system do, but not how
– Do not introduce design or implementation artefacts
• design: definition of a software solution that satisfies the requirements
– Technological solutions for implementing the requirements on the system
– construction of a model of the system before effectively building it
(model of the software)
– Includes aspects of implementation: design patterns, class libraries,
components, persistence mechanisms, etc.
– Introduces new artefacts: an object of analysis may be implemented by a group of
design objects
– Takes into account the implementation platform (machines, operating systems,
languages, etc.), as well as considerations of efficiency, throughput, optimization
of resources, fault-tolerance, etc.
• Difficult to determine where the analysis ends and where the design begins
Juan Llorens - Software Design Overview 17
4 – Tools (Not only SW tools)
• The importance for a SW Engineer to understand their existence
• To be a professional Software engineer you must be skilled, trained and
experienced in the way the existing tools can be applied within a Software
Design.
• Tools must be organized. The Tool-Set Bag.
– Build a tool-set bag during our course.
Juan Llorens - Software Design Overview 18
Lets build a personal Tool-Set Bag
Type Tool Type Tool Type Tool
General Conceptual Abstraction Computational Object Orientation Engineering Modeling
General Conceptual Encapsulation Engineering Diagramming
Organizational Record
Specifications in
video
SW CASE
SW Lower CASE
SW Higher CASE
Juan Llorens - Software Design Overview 19
Modelling tools
• What can offer a CASE tool for UML?
– Drawing
– Syntactical verification
– Consistency between diagrams
– Integration with other
applications
– Group work
– Reutilization
– Code generation...
• Examples
– Rational Rose
– Visual UML
– SWReuser
Juan Llorens - Software Design Overview 20
6 - Documentation Guidelines
ESA PSS-05-04 Issue 1 Revision 1 (March 1995) -THE ARCHITECTURAL DESIGN DOCUMENT
Service Information: 4 System Design
a - Abstract 4.1 Design method
b - Table of Contents
4.2 Decomposition description
c - Document Status Sheet
d - Document Change Records made 5 Component Description
since last issue 5.n [Component identifier]
1 Introduction 5.n.1 Type
1.1 Purpose 5.n.2 Purpose
1.2 Scope 5.n.3 Function
1.3 Definitions, acronyms and 5.n.4 Subordinates
abbreviations 5.n.5 Dependencies
1.4 References 5.n.6 Interfaces
1.5 Overview 5.n.7 Resources
5.n.8 References
2 System Overview 5.n.9 Processing
3 System Context 5.n.10 Data
3.n External interface definition 6 Feasibility and Resource Estimates
7 Software Requirements vs Components
Traceability matrix
Juan Llorens - Software Design Overview 21
Documentation Guidelines
ESA PSS-05-05 Issue 1 Revision 1 (March 1995) 75 THE SOFTWARE USER MANUAL
Service Information: (c) Procedures, including,
a - Abstract - Set-up and initialisation
b - Table of Contents - Input operations
c - Document Status Sheet - What results to expect
d - Document Change Records made since last (d) Probable errors and possible causes)
issue.
1 INTRODUCTION 4 [REFERENCE SECTION]
1.1 Intended readership (Describe each operation, including:
1.2 Applicability statement (a) Functional description
1.3 Purpose (b) Cautions and warnings
1.4 How to use this document (c) Formal description, including as appropriate:
1.5 Related documents (including applicable - required parameters
documents) - optional parameters
1.6 Conventions - default options
1.7 Problem reporting instructions - order and syntax
2 [OVERVIEW SECTION] (d) Examples
(The section ought to give the user a general (e) Possible error messages and causes
understanding of what parts of software provide (f) Cross references to other operations)
the capabilities needed)
Appendix A Error messages and recovery procedures
3 [INSTRUCTION SECTION]
Appendix B Glossary
(For each operation, provide...
Appendix C Index (for manuals of 40 pages or more)
(a) Functional description
(b) Cautions and warnings
Juan Llorens - Software Design Overview 22
How to perform CB software design
Design activities
Data
Architectural Abstract Interface Component Algorithm
structure
design specification design design design
design
LayerN
S2 S2 Layer2
Layer1
Layered Architecture
S1 Repository S3 Inference
Engine
Knowledge
Base
SS2
Repositor
S1 SS1 Repository SS3 y
S3 Execution
DataBas
e
Engine
Repository Architecture
Rule Based Architecture
Juan Llorens - Software Design Overview 23
How to perform CB software design
Design activities
Data
Architectural Abstract Interface Component Algorithm
structure
design specification design design design
design
a b c d e
p
q
s
t
r
Juan Llorens - Software Design Overview 24
How to perform Architectural Design
• Software Architectural Design is
concerned with decomposing a
software sub-system into further
interacting sub-systems.
• Sw Architectural Design =
sub-systems engineering
Juan Llorens - Software Design Overview 25
How to perform Architectural Design:
Sub-system / module Decomposition
A D E
A1 A2 A3
D1 D2 D3 E1 E2 E3
A11 A12 A13
Available Tools:
• Decomposition
A13 A13 • Abstraction
Juan Llorens - Software Design Overview 26
System Decomposition Layers for OO methods
Level 1 Level m Level n-1 Level n
(...)
Sub-system Module Component Class / Object
Juan Llorens - Software Design Overview 27
System Decomposition Layers for OO methods
Level 1 Level m Level n-1 Level n
(...)
Sub-system Module Component Class / Object
Detailed Design
Ways to represent them
Boxes Boxes Boxes | -
Box and Lines Diagrams Box and Lines Diagrams | UML Classes
UML Packages | UML Components UML Components | UML Objects
Diagrams with Packages | UMLComponents Diagrams | UML Class Diagrams
Juan Llorens - Software Design Overview 28
How to perform Object Oriented Detailed Design
• Detailed Design is the process of decomposing a module/system
into objects.
• This decomposition can be affected by:
– Encapsulation, granularity, dependency, flexibility, performance, evolution,
reusability, etc.
[Link], R. Helm, R. Johnson, J. Vlissides. Design Patterns. Elements of Reusable Object Oriented Software
• The Inputs to OO Detailed Design must be:
– The Requirements affecting design
– The Domain Objects and Classes found in Requirements Analysis (RA)
– The Domain Objects and Classes collaborations defined in RA
– The SW Architecture (including Architectural Objects and classes when
they exist)
– The Modules/sub-systems solution principles if they were defined in the
Architectural Design
Juan Llorens - Software Design Overview 29
How to perform Object Oriented Detailed Design
• The Outputs to be produced in an OO Detailed Design must be
– The objects structure
– Their corresponding classes structure (interfaces, Attributes, Operations)
– The collaborations between the objects (messages, signals,..)
– The definition of the possible states of the objects
– The organization of the objects in components and nodes
– The way the structures, states and collaborations can be tested
Juan Llorens - Software Design Overview 30
How to perform Object Oriented Detailed Design
• Therefore, the problem in detailed design can be located in
“how to organize, integrate and adapt the domain and architectural objects, as
well as their structure, interfaces, operative, collaborations and states”.
• Many problems, specific to Object Orientation, may oblige to
include new specific objects (Detailed Design Objects) to solve
them.
• Many of these problems have already been solved and the
objects/classes structures are available for us designers..
They are forming the Design Patterns
Juan Llorens - Software Design Overview 31
Identified problems in Object Oriented Detailed Design
• Not setting the focus on the collaboration
• Finding Appropriate Objects
• Determining Object Granularity
• Specifying Object Implementations
– Class versus type: Specifying object interfaces
– Programming to an Interface / Programming to an Implementation
– The creation of objects
– Inheritance versus Composition
– Delegation
– Inheritances versus Parameterized Types
– The structures of Objects
– The behavior of Objects
– Coupling
• Relating Run-Time and Compile-Time structures
• Designing for Change
[Link], R. Helm, R. Johnson, J. Vlissides. Design Patterns. Elements of Reusable Object Oriented Software
Juan Llorens - Software Design Overview 32
Find Appropriate Objects
• Many objects in a design come from the analysis model. But
object-oriented designs often end up with classes that have no
counterparts in the real world. Some of these are low-level
classes like arrays. Others are much higher-level.
– By using Design Patterns, for example, the Composite pattern introduces
an abstraction for treating objects uniformly that doesn't have a physical
counterpart. Strict modeling of the real world leads to a system that
reflects today's realities but not necessarily tomorrow's. The abstractions
that emerge during design are key to making a design flexible.
[Link], R. Helm, R. Johnson, J. Vlissides. Design Patterns. Elements of Reusable Object Oriented Software
Juan Llorens - Software Design Overview 33
Determining Object Granularity
• Objects can vary tremendously in size and number. They can
represent everythink down to the hardware or all the way up to
entire applications
– Design patterns help you identify less-obvious abstractions and the
objects that can capture them. For example, objects that represent a
process or algorithm don't occur in nature, yet they are a crucial part of
flexible designs. The Strategy (315) pattern describes how to implement
interchangeable families of algorithms. The State (305) pattern represents
each state of an entity as an object. These objects are seldom found
during analysis or even the early stages of design; they're discovered later
in the course of making a design more flexible and reusable.
[Link], R. Helm, R. Johnson, J. Vlissides. Design Patterns. Elements of Reusable Object Oriented Software
Juan Llorens - Software Design Overview 34