SOFTWARE ENGINEERING SOFTWARE DESIGN Saulius Ragaišis saulius.ragaisis@mif.vu.lt
CSC2008 SE Software Design Learning Objectives: Discuss the properties of good software design including the nature and the role of associated documentation. Evaluate the quality of multiple software designs based on key design principles and concepts. Select and apply appropriate design patterns in the construction of a software application. Create and specify the software design for a medium-size software product using a software requirement specification, an accepted program design methodology (e.g., structured or object-oriented), and appropriate design notation. Conduct a software design review of open-source materials using appropriate guidelines. Evaluate a software design at the component level. Evaluate a software design from the perspective of reuse.
DESIGN CONCEPTS
Definition Design is the process of transforming customer requirements, business needs, and technical considerations into the formulation of a product or system. Design is a meaningful engineering representation of something that is to be built. It can be traced to a customer's requirements and at the same time assessed for quality against a set of predefined criteria for 'good' design. Design focuses on four major areas of concern: data, architecture, interfaces, and components.
Design quality R. McLaughlin: The design must implement all of the explicit requirements. The design must be a readable, understandable guide for further activities. The design should provide a complete picture of the software
Fundamental concepts Abstraction: data, procedure, control Architecture: the overall structure of the software Patterns: conveys the essence of a proven design solution Separation of concerns: any complex problem can be more easily handled if it is subdivided into pieces Modularity: compartmentalization of data and function Hiding: controlled interfaces Functional independence: single-minded function and low coupling Refinement: elaboration of detail for all abstractions
Fundamental concepts (2) Aspects: a mechanism for understanding how global requirements affect design Refactoring: a reorganization technique that simplifies the design OO design concepts: Inheritance: all responsibilities of a superclass is immediately inherited by all subclasses Messages: stimulate some behavior to occur in the receiving object Polymorphism: a characteristic that greatly reduces the effort required to extend the design Design Classes: provide design detail that will enable analysis classes to be implemented
Cohesion and coupling Cohesion is an indication of the relative functional strength of a module. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. Coupling is an indication of the relative interdependence among modules. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.
Dimensions of the design model
DESIGN PATTERNS
Patterns Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution a million times over, without ever doing it the same way twice Christopher Alexander, 1977
Design Patterns: Elements of Reusable Object-Oriented Software Author(s) : Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (The "Gang of Four") Subject(s) : Design patterns, software engineering, object-oriented programming Publisher : Addison-Wesley Publication date : 1994 Pages: 395 ISBN: 0-201-63361-2
Design patterns (GoF) Description of communicating objects and classes that are customized to solve a general design problem in a particular context Names, abstracts, identifies key aspects of a common design structure that makes it useful for creating a reusable object-oriented design. Bigger than single class, smaller than whole framework/application
Design pattern elements Pattern name: Handle for describing design problem Problem: When to apply pattern. Explains problem and its context. Solution: Elements making up design (relationships, responsibilities, collaborations) Consequences: Results and trade-offs of applying pattern (implementation issues, performance, reuse etc.)
Design pattern description Name: Essence in one word Intent: Short statement Also known as: Alias Motivation: Concrete scenario Applicability: Situations for application Structure: Graphical representation of design (UML) Participants: Classes and objects Collaborations: How participants collaborate Consequences: Results, trade-offs of use Implementation: Pitfalls, hints, variations Sample code Known uses Related patterns
Gang of Four patterns 23 design patterns Organized in 2 dimensions: Scope: class object Purpose: creational (how to create objects) structural (composition of classes and objects) behavioral (ways of interaction and distribution of responsibility)
General themes Loose coupling: Add indirection to achieve decoupling, flexibility and reuse Abstraction: Naming, encapsulation, parameterization (same purpose as above) Dynamic : Delegation instead of implementation inheritance Object-orientation: object-oriented (re)design Principles of object-oriented design: Program to an interface, not an implementation Favor object composition over class inheritance.
GoF patterns list Abstract factory Builder Factory method Prototype Singleton Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor
Singleton Lazy initialization public class SingletonDemo { private static SingletonDemo instance = null; private SingletonDemo() { } public static SingletonDemo getinstance() { if (instance == null) { synchronized (SingletonDemo.class){ if (instance == null) { instance = new SingletonDemo (); } } } return instance; } }
Composite pattern
GoF patterns overview Composite: Define tree-like structure, where internal and leaf nodes have same interface. Decorator: Functional composition of objects with same interface. Chain of responsibility: Chain objects and delegate requests along the chain. Proxy: Define local object that delegates (most) functionality that other objects.
GoF patterns overview (2) Command: Turn requests into objects Interpreter: Define (programming) language of requests Strategy: Parameterize over different algorithms Visitor: Receive and invoke any programmable operation on object (not just built-in methods)
GoF patterns overview (3) Singleton: Make sure only one instance of a class exists during any program run (shared state) Adapter: Connect two (existing) interfaces (have class with interface I1, and another one that needs I2) Flyweight: Split object state into mutable (context) and immutable (flyweight) and share flyweights. Iterator: Iterate over collection
GoF patterns overview (4) Facade: Centralize interface for collection of classes Mediator: Localize control, make centralized controller for orchestrating collaborating objects Memento: Checkpoint object (save state) Observer: Publish-subscribe interface for pushing state changes to arbitrary number of clients State: Object-oriented state representation for finite state machines
ARCHITECTURAL DESIGN
Software architecture Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]
Key characteristics of architecture defines structure; defines behavior; focuses on significant elements; balances stakeholder needs; embodies decisions based on rationale; may conform to an architectural style; is influenced by its environment; influences team structure; is present in every system; has a particular scope.
Architectural style Center hall colonial house Software architectural style describes a system category that encompasses: a set of components that perform a function required by a system; a set of connectors that enable communication, coordination and cooperation among components; constraints that define how components can be integrated to form the system; semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.
Taxonomy of architectural styles Data-centered architecture Data flow architectures Call and return architectures Object-oriented architectures Layered architectures
Architectural patterns Architectural patterns define some specific approach for handling some behavioral characteristics of the system. Concurrency: applications must handle multiple tasks in a manner that simulates parallelism: operating system process management pattern task scheduler pattern
Architectural patterns (2) Persistence: data persists if it survives past the execution of the process that created it. Two patterns are common: a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture an application level persistence pattern that builds persistence features into the application architecture Distribution: the manner in which systems or components within systems communicate with one another in a distributed environment: a broker acts as a middle-man between the client component and a server component
Architectural Design The software must be placed into context A set of architectural archetypes should be identified The designer specifies the structure of the system by defining and refining software components that implement each archetype
Assessing alternative architectures 1. Collect scenarios. 2. Elicit requirements, constraints, and environment description. 3. Describe the architectural styles/patterns that have been chosen to address the scenarios and requirements. 4. Evaluate quality attributes by considered each attribute in isolation. 5. Identify the sensitivity of quality attributes to various architectural attributes for a specific architectural style. 6. Critique candidate architectures (developed in step 3) using the sensitivity analysis conducted in step 5.
Architectural complexity The overall complexity of a proposed architecture is assessed by considering the dependencies between components. Types of dependencies: Sharing dependencies: relationships among consumers who use the same resource or producers who produce for the same consumers. Flow dependencies: relationships between producers and consumers of resources. Constrained dependencies: constraints on the relative flow of control among a set of activities.
Architectural description languages Architectural description language (ADL) provides a semantics and syntax for describing a software architecture. Provide the designer with the ability to: decompose architectural components compose individual components into larger architectural blocks represent interfaces (connection mechanisms) between components
Structured design Objective: to derive a program architecture that is partitioned. Approach: a DFD is mapped into a program architecture the PSPEC and STD are used to indicate the content of each module Notation: structure chart
Why partitioned architecture? results in software that is easier to test leads to software that is easier to maintain results in propagation of fewer side effects results in software that is easier to extend
Partitioning the architecture Horizontal partitioning: define separate branches of the module hierarchy for each major function; use control modules to coordinate communication between functions. Vertical partitioning: design so that decision making and work are stratified; decision making modules should reside at the top of the architecture.
COMPONENT-LEVEL DESIGN
Definition of component OMG UML Specification: a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. OO view: a component contains a set of collaborating classes Conventional view: a component contains processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it.
Basic design principles The Open-Closed Principle (OCP). A module [component] should be open for extension but closed for modification. The Liskov Substitution Principle (LSP). Subclasses should be substitutable for their base classes. Dependency Inversion Principle (DIP). Depend on abstractions. Do not depend on concretions. The Interface Segregation Principle (ISP). Many client-specific interfaces are better than one general purpose interface. [R. Martin]
Basic design principles (2) The Release Reuse Equivalency Principle (REP). The granule of reuse is the granule of release. The Common Closure Principle (CCP). Classes that change together belong together. The Common Reuse Principle (CRP). Classes that aren t reused together should not be grouped together. [R.Martin]
Design Guidelines Components Interfaces Dependencies and inheritance Cohesion Coupling
Design steps 1. Identify all design classes that correspond to the problem domain. 2. Identify all design classes that correspond to the infrastructure domain. 3. Elaborate all design classes that are not acquired as reusable components. a. Specify message details when classes or component collaborate. b. Identify appropriate interfaces for each component. c. Elaborate attributes and define data types and data structures required to implement them. d. Describe processing flow within each operation in detail.
Design steps (2) 4. Describe persistent data sources (databases and files) and identify the classes required to manage them. 5. Develop and elaborate behavioral representations for a class or component. 6. Elaborate deployment diagrams to provide additional implementation detail. 7. Factor every component-level design representation and always consider alternatives.
Designing conventional components The design of processing logic is governed by the basic principles of algorithm design and structured programming. The design of data structures is defined by the data model developed for the system. The design of interfaces is governed by the collaborations that a component must effect. Design notations: Graphical: flowcharts. Tabular: decision table. Program Design Language (PDL).
USER INTERFACE DESIGN
Typical user-interface design errors?
Golden rules Place the user in control Reduce the user s memory load Make the interface consistent
Place the user in control Define interaction modes in a way that does not force a user into unnecessary or undesired actions. Provide for flexible interaction. Allow user interaction to be interruptible and undoable. Streamline interaction as skill levels advance and allow the interaction to be customized Hide technical internals from the casual user. Design for direct interaction with objects that appear on the screen.
Reduce the user s memory load Reduce demand on short term memory. Establish meaningful defaults Define shortcuts that are intuitive The visual layout of the interface should be based on a real world metaphor Disclose information in a progressive fashion.
Make the interface consistent Allow the user to put the current task into a meaningful context. Maintain consistency across a family of applications. If past interactive models have created user expectations, do not make changes unless there is a compelling reason to do so.
User interface design models User model: a profile of all end users of the system. Design model: a design realization of the user model. Mental model (system perception): the user s mental image of what the interface is. Implementation model: the interface look and feel coupled with supporting information that describe interface syntax and semantics.
Categories of users Novices Knowledgeable, intermittent users Knowledgeable, frequent users
User analysis User interviews Sales input Marketing input Support input
Task analysis and modeling Use-cases define basic interaction Task elaboration refines interactive tasks Object elaboration identifies interface objects (classes) Workflow analysis defines how a work process is completed when several people (and roles) are involved Hierarchical representation Analysis of display content Analysis of the work environment
Design issues Response time Help facilities Error handling Menu and command labeling Application accessibility Internationalization
WEBAPP DESIGN
Design & WebApp Quality Security Availability Scalability Time to market
Quality dimensions for end-users Time Structural Content Accuracy and Consistency Response Time and Latency Performance
Design goals Simplicity Consistency Identity Robustness Navigability Visual appeal Compatibility
Interface design principles Anticipation Communication Consistency Controlled autonomy Efficiency Flexibility Focus Fitt s Law Human interface objects Latency reduction Learnability Metaphors Maintain work product integrity Readability Track state Visible navigation
Aesthetic design Don t be afraid of white space. Emphasize content. Organize layout elements from top-left to bottom right. Group navigation, content, and function geographically within the page. Don t extend your real estate with the scrolling bar. Consider resolution and browser window size when designing layout.
Content design Develops a design representation for content objects. Represents the mechanisms required to instantiate their relationships to one another. A content object has attributes that include contentspecific information and implementation-specific attributes that are specified as part of design.
Architecture design Content architecture focuses on the manner in which content objects (or composite objects such as Web pages) are structured for presentation and navigation. WebApp architecture addresses the manner in which the application is structured to manage user interaction, handle internal processing tasks, effect navigation, and present content. Architecture design is conducted in parallel with interface design, aesthetic design and content design.
Navigation design Navigation semantics Navigation syntax: Individual navigation link Horizontal navigation bar Vertical navigation column Tabs Site maps
Component-level design Functionality of WebApp components: perform localized processing to generate content and navigation capability in a dynamic fashion; provide computation or data processing capability that are appropriate for the WebApp s business domain; provide sophisticated database query and access; establish data interfaces with external corporate systems.
DESIGN FOR REUSE
Benefits of software reuse Increased reliability: reused software has been tried and tested in working systems. Reduced process risk: the cost and risk of existing software is already known. Effective use of specialists: reusable software encapsulates their knowledge. Standards compliance: embed standards in reusable components. Accelerated development: both development and validation time may be reduced.
Problems with reuse Increased maintenance costs: reused elements of the system may become increasingly incompatible with system changes. Not-invented-here syndrome: companies rewrite components because they believe they can improve them or because they feel they must own them. Creating, maintaining, and using a component library: generality of components doesn t come for free; development process have to be adapted. Finding and understanding components: software components have to be discovered in a library, understood, and sometimes adapted.
Reuse at architecture level Architectural patterns: standard SW architectures Application frameworks: classes at system level Legacy system wrapping: interfaces to old code Service-oriented systems: shared (third-party) services
Reuse at design level Object orientation: object design and development Design patterns: reusable software solutions Aspect-oriented software development: perspectives Component-based development: CBSE, component-model
Component development for reuse Components for reuse may be specially constructed by generalizing existing components. Component reusability Should reflect stable domain abstractions Should hide state representation Should be as independent as possible Should publish exceptions through the component interface There is a trade-off between reusability and usability. The more general the interface, the greater the reusability but it is then more complex and hence less usable
Reusable components The development cost of reusable components is higher than the cost of specific equivalents. This extra reusability enhancement cost should be an organization rather than a project cost Generic components may be larger and slower than their specific equivalents
Reusability enhancement Name generalization Names in a component may be modified so that they are not a direct reflection of a specific application entity Operation generalization Operations may be added to provide extra functionality and application specific operations may be removed Exception generalization Application specific exceptions are removed and exception management added to increase the robustness of the component Component certification Component is certified as reusable
What we have learned? Fundamental design concepts and principles Understanding of design patterns Architectural design Component-level design User interface design WebApp design Design for reuse
QUESTIONS?
APPENDIX