Software Architecture
Detailed Design
Agenda
I. Overview of detailed design
II. Key tasks in detailed design
III. Design best practices
IV. Case Study - Example
V. Summary
Overview
❑ The goal of the detailed design is to specify the internal
structure and behavior of components.
What’s detailed design?
➢ According to the IEEE [1],
1. The process of refining and expanding the preliminary design phase of
a system or component to the extent that the design is sufficiently
complete to be implemented .
2. The result of the process in 1.
➢ To keep terminology consistent, we’ll use the following
definition:
1. The process of refining and expanding the software architecture of a
system or component to the extent that the design is sufficiently
complete to be implemented .
2. The result of the process in 1.
➢ During Detailed Design designers go deep into each component to define
its internal structure and behavioral capabilities, and the resulting design
leads to natural and efficient construction of software.
Key tasks in detailed design
➢ The major tasks identified for carrying out the detailed
design activity include:
1. Understanding the architecture and requirements
2. Creating detailed designs
3. Evaluating detailed designs
4. Documenting software design
5. Monitoring and controlling implementation
[Link] the architecture and
requirements
2. Creating detailed design
➢ After the architecture and requirements for assigned components are well
understood, the detailed design of software components can begin.
✓ Detailed design consist of both structural and behavioral designs.
➢ When creating detailed designs, focus is placed on the following:
1. Interface Design - Internal & External
2. Graphical User Interface (GUI) Design
▪ This may be a continuation of designs originated during architecture.
3. Internal Component Design
▪ Structural
▪ Behavioral
4. Data Design ~ Database ; data dictionary
3. Evaluating detailed designs
➢ Logical designs are verified using static techniques; that is, through non-
execution of the software application.
✓ This makes sense since at this point, the software has not been
constructed!
➢ The most popular technique for evaluating detailed designs involves
Technical Reviews. When conducting technical reviews, keep in mind the
following:
✓ Send a review notice with enough time for others to have appropriate
time to thoroughly review the design.
✓ Include a technical expert in the review team, as well as stakeholders
of your design.
✓ Include a member of the software quality assurance or testing team in
the review.
✓During the review, focus on the important aspects of
your designs; those that show how your design helps
meet functional and non-functional requirements.
✓Document the review process.
▪ Make sure that any action items generated during the
review are captured and assigned for processing.
4. Documenting detailed designs
➢ Documentation of a project’s software design is mostly captured in the
software design document (SDD), also known as software design
description. The SDD is used widely throughout the development of the
software.
✓ Used by programmers, testers, maintainers, systems integrators, etc.
➢ Other forms of documentation include:
✓ Interface Control Document
▪ Serves as written contract between components of the system
software as to how they communicate.
✓ Version Control Document
▪ Contains information about what is included in a software release,
including different files, scripts and executable. Different versions of
the design depend on specific software release.
5. Managing implementation
➢ Monitor and control detailed design synchronicity
➢ Detailed design synchronicity is concerned with the degree of how well
detailed designs adhere to the software architecture and how well
software code adheres to the detailed design.
✓ Forward & backward traceability
✓ Low degree of synchronicity points to a flaw in the process and can
lead to software project failure.
➢ Particular attention needs to be paid when projects enter the maintenance
phase or when new engineers are brought into the project.
➢ Processes must be in place to ensure that overall synchronicity is high
Design best practices
❑ Design for extensibility
❑ Design for performance
❑ Design for portability
❑ Design for testability
❑ Adding details to the domain model
❑ Design heuristics
1. Design for Extensibility
❑ Extensibility is the ability of a software to allow and accept
significant extension of its functionalities without major
changes in its design.
❑ Extensibility principles. An extensible design:
✓ is open to changes.
✓ addresses a class of problems instead of a single
problem.
✓ does not contain immature/fuzzy concepts.
Design patterns for extensibility
What varies Design Patterns
Algorithm Strategy,Visitor
Actions Command
Implementation Bridge
Reactivity to changes Observer
Interaction between objects Mediator
Object creation Fabric, Prototype
Created structure Builder
Traversal algorithm Iterator
Object interface Adapter
Object behavior Decorator, State
Reify Variants
❑ Apply the Abstract Factory design pattern to dynamically
configure products from the same family.
Applying the Abstract Factory
Reify States
❑ Apply the State design patterns for each state chart.
Applying the State Pattern
Reify Events
❑ Apply the Command design pattern to implement events
2. Design for Performance
❑ Performance is the degree to which a system or
component accomplishes its designated functions within
given constraints regarding processing time and
throughput rate.
❑ Efficiency is the capability of the software product to
provide appropriate performance, relative to the amount
of resources used under stated conditions.
Design Performance Principles
❑ Implement correctly at first, then measure performance
and optimize it, if necessary.
❑ Maintain consistency between different representations:
• Verify that the optimized version is equivalent to the
non-optimized one.
❑ Use, when necessary, different programming paradigms:
• Create interfaces to separate the two paradigms.
• Do not mix paradigms: do not pollute one side with other
side concepts.
Code Optimization Rules
❑ Optimization of Attributes
❑ Optimization of Operations
❑ Lazy loading of objects
❑ Proxy Pattern Application
3. Design for Portability
❑ Portability is the ease with which the software product can
be transferred from one hardware or software
environment to another.
❑ Levels of portability:
✓ Code: the software is adapted in its source-level, then
recompiled for the new target environment.
✓ Virtual Machine: the software is compiled into
intermediate form (byte code), and executed on
platform-specific virtual machines.
✓ Binary:This the software is ported directly in its
executable form, usually with little adaptation.
Portability Principles
❑ Control the interfaces:
✓ identify all interfaces to the environment, and cast them
in a standard form wherever possible.
❑ Isolate dependencies:
✓ recognize the portions of a software unit which must be
adapted, and isolate these portions.
❑ Think portable:
✓ the designer must be constantly aware of his part of the
likelihood of future porting, and the impact on
portability of all design decisions.
Portability at code level
❑ Portability is often treated at code level. Some examples:
✓ Java, XUL (XML User Interface Language).
✓ Posix (Portable Operating System Interface).
✓ CORBA (Common Object Request Broker Architecture),
etc.
❑ Limits:
✓ Same user interface for different graphical
environments.
✓ No integration with other software (calendar, address
book, etc.)
Portability at Design Level
❑ Develop different version of the same
component.
❑ For instance, a GUI for: KDE, Gnome, Windows,
etc.
Portability in Firefox
❑ XUL (XML User Interface Language), a powerful widget-
based markup language.
❑ Includes a set of cross-platform widgets
❑ Based on existing standards
✓ Cascading Style Sheets (CSS)
✓ Document Object Model (DOM)
✓ JavaScript, including E4X (ECMAScript for XML)
✓ XML, SVG, MathML
❑ XUL user interfaces can run on Windows, Mac and Linux
(Platform portability).
❑ Easy localization: locale specific resources are easily
separated from presentation and code.
4. Design for Testability
❑ Testability is the capability of a software product to enable
modified software to be tested.
❑ Factors that influence testability:
✓ Controllability:
▪ the better we can control the software (in isolation),
the more and better testing can be done, automated,
and optimized.
✓ Observability:
▪ what you see is what can be tested. Ability to observe
the inputs, outputs, states, internals, error conditions,
resource utilization, and other side effects of the
system under test.
Other Factors
❑ Suitability: clarity of specifications.
❑ Stability: how often the code changes
❑ Performance: how fast it works
❑ Diagnosability: how fast defects can be localized.
Improving Controllability
❑ Use interfaces:
✓ they simplify integration test by creating mock objects
and stubs.
❑ Separate Input/Output Interfaces from the rest of the
code:
✓ they cannot be directly automatized.
Improving Observability
❑ Use the public visibility when possible
✓ private operations cannot be tested.
✓ private attributes cannot be read.
❑ Use a Logging module
✓ Define levels (Verbose, Info, Warning, Error, Critical).
✓ Use the last two for urgent notifications.
❑ Use observable middleware (e.g. CORBA bus).
Improving Diagnostic
❑ Use unit tests (small granularity tests).
❑ Use assertions in code.
Improving Integration Test
❑ Use dependencies on class, component, and package
diagrams: «uses», «creates», etc.
✓ Class coupling highlight.
✓ Simplification of the integration plan.
5. Adding Details to the domain model
❑ Specialization/Generalization Adjustment:
✓ Look for reuse: make similar what is almost similar:
▪ Possible changes of operation signatures and
attribute types.
✓ Abstract common behaviors and properties.
Attributes
❑ Precise:
✓ Default values
✓ Multiplicities: [0..1], [*], etc.
✓ Constraints (OCL expressions).
✓ Modifiers: readOnly, redefines, etc.
✓ Visibility.
✓ Use OCL to precise derived attribute
Object Constraint Language
6. Design Heuristic
❑ Heuristic:
✓ Avoid god classes:
▪ systems composed of a class that controls everything
and of several data classes.
✓ Distinguish specialization and aggregation:
▪ if the choice is possible, use aggregation instead of
specialization.
Specialization
❑ Avoid concrete classes specialization.
❑ Super classes should be abstract.
❑ Super-classes should not know subclasses.
❑ Specialization hierarchies should be shallow.
Specialization
❑ If two classes share the same properties but not the same
behavior, those properties should be moved to a third
class.
❑ The behavior related to these properties will intuitively
follow them.
Attributes
❑ Attributes should be hidden
❑ Setter and Getter methods are not essentials: they
prevent good design choices.
❑ Prefer private attributes rather than protected and
protected rather than public.
Classes
❑ Clients of a class must be dependent on its public
interface, but a class should not be dependent on its
clients.
❑ Define a minimal interface for all classes.
❑ For instance: copy(), deepCopy(), equals(), fromString(),
toString(), etc.
Classes (cont)
❑ A class should represent one and only one abstraction.
❑ The classes are abstractions of the real and not the
different roles played by an object.
❑ Be suspicious with classes whose names are verbs:
✓ they may be an operation.
✓ in some cases, they are indeed an operation (see
Command and Strategy patterns).
Operation
❑ Feature envy: operations of a class should use
properties (and other operations) of this same class.
❑ Common behavior of public operations should be placed in
private methods.
Case Study
Conclusion
❑ Separate interface and implementation.
❑ Separate what is common from what is variable.
❑ Use a common interface to allow variable implementations
to be replaced.
❑ Use design patterns for ensuring variability and
extensibility.
Summary
❑ Overview of detailed designed
❑ Tasks in detailed design
❑ Detailed design principles
✓ Design for extensibility
✓ Design for performance
✓ Design for portability
✓ Design for testability
✓ Adding details to the domain model
✓ Design heuristics
❑ Apply design patterns in details design
References