software design requirements design code-implementation test case design builds testing rel....
DESCRIPTION
Design of Software Product Designers are interested not only in the code, but the complete product which includes: –Documentation and User Instructions –Code (functionality, data, security, reliability, etc.) –Interfaces (both systems and user) –Packaging and Delivery Scheme –Installation –Service (including maintenance) This seems like a lot of topics that software designers must cover !! So, there are specializations within the field of software design.TRANSCRIPT
Software Design
Requirements
Design
Code-Implementation
Test Case Design
Builds
Testing
Rel.
Maintenance
Reqs. may be from customer or “home invented”
Important “End-Results” of Design
• “Well-Designed” software results in final solution that is:
• Easy to learn/understand • Easy to use
• Easy to code• Easy to maintain (Extensible)
• Affordable (economical)• Reusable• Dependable• Valuable (increase user productivity, life saving, etc. – meets
customer requirements )
Which ones do the “users” care?
Any other property that you may want to add? -- easy to integrate or test --- secure ---?
Clear, Consistent, Complete?
Design of Software Product
• Designers are interested not only in the code, but the complete product which includes:
– Documentation and User Instructions– Code (functionality, data, security, reliability, etc.) – Interfaces (both systems and user)– Packaging and Delivery Scheme– Installation– Service (including maintenance)
This seems like a lot of topics that software designers must cover !!So, there are specializations within the field of software design.
Software “Product” Design is the activity of specifying: - the nature and - composition of software products that satisfy the clients’ - needs and - desires subject to certain set of constraints
What are the concepts behind “nature of” versus “composition of” ?
What about “needs” versus “desire” ?
Design as an “Activity” (verb)
Understanding the Problem• Design occurs “after” requirements (which identifies the
“problems”)– “after” is fuzzy time boundary – there is no clean boundary
• Think of Design as both a) understanding & b) solving “problems”1. Customer (user) identification of problem (requirements)
sometimes borders on solution --- but is really a constraint. Thus we should thoroughly “understand” problems
2. For each problem there may be several solutions or designs that apply
3. Use some “time-honored” problem solving techniques• Modifying the problem slightly to
– a) facilitate easier/cheaper solution or – b) to match previously solved problem
• Trial and error (e.g. iterative prototyping is the fancy term)• Group brainstorming (I only recommend a “small” group)
Two Basic Design Techniques• Abstraction
– Focusing on the “relevant” properties of an entity by suppressing and ignoring some other properties and the details ----- trick is deciding on the “relevant.”
• Modeling
– Constructing a model “entity” to represent the real entity of interest through:• Associating : parts of the model to the parts of the real
entity• Associating: the relationships among parts of the model to
the relationships among parts of the entity of interest.
2 aspects of Abstraction
• A) Problem/Solution “Simplification”: concentrating on only the key property – (For example): In drawing a figure, we choose to first focus on
shape of the figure (e.g. circle, oval, rectangle, diamond, etc.) before worrying about the details ( color, the line width, solid/dotted line, etc.) ---- based on past experiences?
• B) Problem/Solution “Refinement: simplify first and then enhance the solution with more details– Top-down refinement (Decomposition): partition the problem
into several key components first and then solve the details of each component• Bottom-up aggregation: solving pieces of a complex problem and
then aggregate the solutions• Note: Bottom-up solution usually requires a top-down framework of
key components.
Modeling• Modeling is based on problem/solution “simplification” aspect of
Abstraction.– Decide on the key components (abstraction) of the entity of interest.– Decide on the key relationships that exist among the components of
the entity of interest.– Construct the components of the model to represent the
components of the entity of interest.– Construct the relationships among the components of the model to
reflect the relationships among the components of the original entity of interest.
• In doing so:– There may be parts in the model that do not match the original entity– There may be relationships in the model that do not match that in the
original entity • Note: If everything matched, then the model would just be a
“copy,” not an abstraction of the original entity.
Modeling: “components” and “relations”
“Thing-X” thatNeeds modeling Part C Part D
Part BPart A
Part F
modeling
Another Definition of Design (from K. Lano)
• Design is the activity of (i) “constructing” components and (ii) “organizing” their interactions in order to achieve the system that will satisfy the requirements.– Components:
• Identifying/specify -- the components• Specifying --- their functionalities• Specifying --- any constraints (performance, security, etc.)
– Interactions:• Identify and Specify Component relations (for OO classes -----
inheritance, aggregation, etc.)• Identify and Specify Component dependencies/interactions
(interfaces, joint responsibilities, sequences of interactions, etc.)
Compare this with previous definition --- is this a better refinement?
Develop a Software Model for A “Solar System”
• Start the discussion of this in class• The remaining parts are given as an
assignment. (see Assignment 1)
For this assignment also think about whatIs a “well constructed” model or design
e.g. easy to understand easy to implement etc.
See earlier slide
“Advantages” of Modeling
• Allows us to understand the problem or requirements better (model of the problem)
• Allows us to create an “initial rough design”
– “Model” of problem develops “Model” of solution
• Allows us to investigate and study both the problem and the solution in more detail
• Allows us to have a documentation of the problem/solution descriptions (models)
Two Types of Design Models
• Static model: – Represents the parts, relationships, and attributes
that do not really change (during execution of the software )
• Dynamic model:– Represents what happens during the execution of
the software.
In this course we will be using both static and dynamic models of software
Software Product Designer & Engineering Designer
• A software product designer is concerned with:– Product features and capabilities– Visually appealing and easy to use user-interfaces– Fitting into users’ business processes and operability– Product packaging** ( a closer tie to what is specified in the product requirements )
• A software engineering designer is concerned with:– Individual functionalities and performance– Internal structure of the software system– Individual programs and their interfaces & interactions– The data flow through the software system (including inputs and
outputs)– System maintenance and evolution ** (a closer tie to the internal technical design )
(similarities and differences?)
Software Design Team • We Need both:
– Software Product Designer– Software Engineering Designer
• Different sets of skills needed:
– Product Designer – knowledge of: user interface, communicating the requirements/product design, marketing, business processes, applications domain knowledge
– Engineering Designer – knowledge of: architecture, programming, database and data structures, development platforms, networking, operating systems
Software Design
Requirements
Design
Code-Implementation
Test Case Design
Builds
Testing
Rel.
Maintenance
product designer
engineering designer
product designer
(product and engineering redesign)
Software Product Design .vs.
Software Engineering Design• Product Design Activity – output is a software requirements
specification document– Answers mostly “what” the user and customer needs and wants ---
formulates the problem in an organized way :• Functionalities & features • Looks and interfaces• Constraints
• Engineering Design Activity – output is a design specification document– Answers mostly “how” the software will be put together to respond
to the users’ needs and wants --- formulates the solution in an organized way• High level software:
– Components and – How they interact– Rationale behind your design decisions ( * my addition )
• Low level specifications of programs and data and their behavior
organize: relating these
Where is the analysis / innovation / creativity? ---- what do you think?
* * * Information/data needs to be folded in also * * *
Is There a Design Method?• There is no ONE design method in the form of a
“recipe” for design.
• There are several methods that all speak to:– Design process: a set of steps that starts with “some inputs”
and transform that input to some output and eventually results in a design specification (e.g. structured method, OO-method, etc.)
– Design notation: a set of symbolic representations and how the symbols are to be used (e.g. UML, DFD, etc.)
– Design “heuristics”: a set of guiding rules (e.g. low coupling and high cohesion)
Note: There are cooking recipes! But most software designs are too large and complex compared to food dishes; so there are no design “recipes” .
More importantly, the mental activities that perform the design (analysis/innovation), I believe, is not easily explainable or understood ---- thus it would be hard to “teach” it!
Brief History of Major Design “Methods”
• Niklaus Wirth; E. Dijkstra (early 1970’s) : Stepwise Refinement– top-down approach that repeatedly decomposed procedures
into smaller ones until we reach programming level.• Stevens, Myers, and Constantine (mid-1970’s):
Structured Design: (also DeMarco; Ross; Mills; etc.)– Also top-down and procedural in nature– Included dataflow diagram and entity-relationship considerations– Started people on using CASE tools and associated notations
provided by the tools• Object Oriented Design (late 1980’s- mid 1990’s)
– Based on “Objects/ Classes” (inheritance, polymorphism, etc.)– Uses standard UML design notation (Booch, Jacobson,
Rumbaugh)
functionalabstraction
functional& dataabstraction
“object”abstraction
- Recently, we are pushing ------ “design with patterns”