CS 575: Software Designbmitchell/course/cs575/introduction.pdf · several entrance tests prior to ... AntiPatterns are a natural extension to design patterns AntiPatterns bridge the

1© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu

CS 575: Software Design

Introduction


Software Design

A software design is a precise description of a system, using a variety of differentperspectives…

Structural Packaging

Behavioral Infrastructure

Requirements,Test/Validation

Criteria


Expressing A Software Design

Software Designs are complicated, therefore,they must be modeled…

Similar to an architects blueprintA model is an abstraction of the underlying problemDesigns should be modeled, and expressed as a series of viewsHelpful to use a modeling language such as UML


Modeling as a Design Technique

Designs are too complicated to develop from scratchGood designs tend to be build using models…

1) Abstract different views of the system2) Build models using precise notations (e.g., UML)3) Verify that the models satisfy the requirements4) Gradually add details to transform the models into the design


Modeling as a Design Technique

Models




Criteria

Lets Build this System…

IncrementalRefinement

DesignDesignLets Start Building this System…


Modeling as a Design Technique -Improved

Models




Criteria

Lets Build this System…

Incremental Refinement

DesignDesignLets Start Building this System…

Frameworks,Patterns,Templates, etc.


Designing With ModelsDesigning With Models

Modeling Designs…

DesignDesign

VeryComplicated

ToUnderstand Modeling Tool

ModelRepository

Visualization


UML – A modeling Notationfor Design

Structural Packaging/Implementation

Behavioral Infrastructure/Environment


Class Diagrams Package DiagramsComponent Diagrams

Criteria

Use CasesSequence DiagramsCollaboration DiagramsStatechart DiagramsActivity Diagrams

Deployment Diagrams


Software Architecture

According to Shaw and Garlan…The Software Architecture of a system consists of a description of the system elements, interactions between the system elements, patterns that guide the system elements, and constraints on the relationships between system elements.

Its a more abstract view of the designIts helpful for communication and complexity management

Problem: There is no standard definition –see http://www.sei.cmu.edu/architecture/definitions.html


The Software Architecture “Stack”

Software Architecture

Subsystem Decomposition

Subsystem Dependencies

Subsystem Interfaces

Module/Class Decompositions

Module/Class Dependencies

Module/Class Interfaces

Data Structures

Algorithms


The Software Architecture “Stack” Software Architecture

Subsystem Decomposition

Subsystem Dependencies

Subsystem Interfaces

Module/Class Decompositions

Module/Class Dependencies

Module/Class Interfaces

Data Structures

Algorithms

High-Level(Abstract)

Design

Low-Level(Detailed)Design


Why do we design…A software design is not necessary for trivialsystems, but for large systems a design is essential

Manage complexityValidation of delivered softwareSimplify future maintenanceA mechanism for communication between domain experts and technical professionalsEnables VisualizationEnables project team members to work concurrently

Partitioning the work effort with limited overlapExample: Concurrently developing test cases while the code is being development


Why is design so hard…

Software design can’t be taught, but principles of good design canThere are degrees of good and bad design, but its hard to say if a design is correct or notThe underlying assumptions and requirements that support the design changeA design is like wine, it takes a long time to see if it is good or not


DesignMethodologies

ExtremeProgramming

Waterfall

Iterative


Software Development Methodology

A Methodology is:A Process

What happens over timeCoupled to the Software Development Lifecycle (SDLC)

A Management ApproachWhat is needed to move from one step to another

Helps with the project management aspects of a software development project


Modeling Emphasis for Different Design Approaches

ComponentOriented

Traditional/Structured

ObjectOriented

Data

Structure

Function


Jumpstarting Design

?

Starting from scratch “blank screen” is tough. Components of a design toolbox – Templates, Patterns, Reference Architectures, Frameworks,and so on…


Example: Jakarta Struts Presentation Framework


Example: J2EE Architecture PatternsSource:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/


Example: Intercepting Filter PatternArchitectural Pattern

Problem: Preprocessing and post-processing of a client Web request and response are required

When a request enters a Web application, it often must pass several entrance tests prior to the main processing stage:

Has the client been authenticated? Does the client have a valid session? Is the client's IP address from a trusted network? Does the request path violate any constraints? What encoding does the client use to send the data? Do we support the browser type of the client?

The key to solving this problem in a flexible and unobtrusive manner is to have a simple mechanism for adding and removing processing components, in which each component completes a specific filtering action.


Design Patterns

Example: Observer Pattern

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

Note: Design pattern references often include samplecode in a variety of languages to illustrate how to usethe pattern.


What’s good about Patterns

They solve common problems in a “proven” wayThey tend not to be implementation specific They tend to be classified in a common way – context, forces, examples, etcThey embody good design principles

Example: Loose Coupling


Design Quality

Software design “quality”, as with other ideas on quality, is an elusive concept:It depends on priorities of your company and the customers:

fastest to implementeasiest to implementeasiest to maintain, “evolve”, portmost efficient/reliable/robust end-product.


How to “Fix” A Software Design

Many times the source code is the only up-to-date documentation for a software system

Must be able to recover the design to some extentMust be able to “improve” the design where appropriate


Improving Existing Designs - Refactoring

See Martin Fowler’s BookWhat is Refactoring:

Refactoring is a technique to restructure code in a disciplined wayUsed to improve a system design in any number of waysPattern/Template based processAutomated tools exist

Refactoring is a behavior preserving transformation ofthe source code…


Example: Refactoring – PushDownMethod

AfterBefore

Bill+setName()+getAddress()

…+send()

Bill+setName()+getAddress()

…#send()

EBill+send()

MailBill+send()

Note: There are manyways to do this type ofrefactoring – this is justone example.


Anti-Patterns (plus Refactoring)AntiPatterns are Negative Solutions that present more problems than they address AntiPatterns are a natural extension to design patterns AntiPatterns bridge the gap between architectural concepts and real-world implementations. Understanding AntiPatterns provides the knowledge to prevent or recover from them

Recovery can be via Refactoring

From: www.antipatterns.com


Antipattern Example: Poltergeists

Proliferation of classes [Riel 96] Spurious classes and associations

Stateless, short-lifecycle classes Classes with few responsibilities Transient associations

Excessive complexity Unstable analysis and design models Analysis paralysis Divergent design and implementation Poor system performance Lack of system extensibility



Antipattern Example: Poltergeists



Antipattern Example: Fixing Poltergeists

Refactor to eliminate irrelevant classes Delete external classes (outside the system) Delete classes with no domain relevance

Refactor to eliminate transient “data classes” Refactor to eliminate “operation classes” Refactor other classes with short lifecycles or few responsibilities

Move into collaborating classes Regroup into cohesive larger classes



Good Design Properties

Hierarchical: A good design should be organized into a well-designed hierarchy of components.Modular: Separate distinct concerns (dataand processing) into distinct containers (i.e.,subsystems, modules, and/or classes). Hide implementation details and provide clean, simple interfaces for each container.



Independent: Group similar things together; limit the amount of “special knowledge” that unrelated components may share. If you change your mind about something, the impact will be localized.



Simple Interfaces: Endless flexibility adds complexity. Complex interfaces mean:

hard to understand by users and developers (e.g., Unix man page syndrome)many possible variations of useinconvenient to change interface in order to eliminate “bad options”.

You can get away with “flexible interfaces” in a low-level localized setting, but the larger the scale, the simpler the interface should be.


Summary: Software DesignGood software designers are experienced software designers

Given a design, and experienced designer can tell you:

What’s good, What’s Bad, and provide suggestions for improvement

Patterns and Frameworks are very helpful to software designers

Good software designs are based on good design principles


Demystifying SOA

Service-Oriented architecture is the latest “buzz” in the information technology and enterprise application domainsThere is a lot of hype, buzzwording and misconception around SOAWe will place a good bit of emphasis in this course examining at SOA to try to understand its pro’s and con’s from an application architecture and design perspective.


SOA – Its an Architecture, Design and Instantiation Approach

Understanding SOA requires one to answer the following questions:

What is a service oriented architecture?What is a service?How do I design an application that adheres to a SOA?How do I implement an application designed using SOA principles?


Traditional versus SOA applications – a line and box view…

Applications designed in conjunction with an SOA style are easier to design, implement, maintain and extend due to the loose coupling of components that reside in different services

The pieces (services) in an SOA are designed with a courser granularity than an design based on traditional components, making the system simpler to deal withThe messaging interfaces between the services in an SOA have structure and semantics allowing them to be intelligently routed and provisioned based on application-specified policies

Traditional Application SOA ApplicationApplication Components Service

Service Service

Messaging


What is a service?

Service (also application service): An application function that (a) within each request, encompasses a complete parcel of work (business or technical), (b) may stand on its own or be part of a larger set of functions that constitute a larger service but its scope is such that each request leaves the system in a long-term steady state, (c) is designed for and provides a network-accessible interface and (d) is designed to receive requests from any source, making no assumptions as to the functional correctness (syntactic or semantic) of an incoming request.


What is a service? – Technically…

ProvidedInterface

RequiredInterface

<<Service>>

C1 C2

C3

Service boundaries are explicitService invocation based on message passing and not method invocation

Services are autonomousServices can be deployed and/or extended independently of the service consumers (i.e., applications)Services can be developed in any language since the binding is in the form of an encoded message in a standard format



ProvidedInterface

RequiredInterface

<<Service>>

C1 C2

C3

Services share schema and contract, not classServices advertise a contract that describes the structure (schema) of messages it can send and/or receive as well as some degree of ordering constraints over those messages. Interfaces are defined in terms of a schema and not binary classesExample: WSDL in Web Services



ProvidedInterface

RequiredInterface

<<Service>>

C1 C2

C3

Service compatibility is determined based on policyDue to the tightly coupled nature of OO and Component designs, they assume that structural compatibility implies semantic compatibilityStructural compatibility in SOA is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy.Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of theservice.


Why SOA – Another Layer of Abstraction

OO abstractions were introduced to deal with the complexity of managing functions independent of dataCBD abstractions were introduced to deal with the complexity of distribution, packaging, and deploymentSOA abstractions were introduced to create the notion of a network-aware, single instance component that can participate in a both synchronous and asynchronous business process


Activates to consider when designing an SOA [ref: http://www.webservices.org/index.php/ws/content/view/full/55441]

SOA separates the concerns of the service consumer andthe service provider.


Logical Layering for SOA [ref: http://www.webservices.org/index.php/ws/content/view/full/55441]

(e.g., ESB)


Services are another layerof Abstraction

Services are special types of components, having a published interface that consists of a subset of one or more public component interfaces that collectively defines the service boundary Components are built from a collection of objects where the emphasis is on creating a deployable package that enables the component to execute in a managed application server container such as .Net or J2EE/WebSphereObjects are compiled code, developed in a specific programming language, that represent the most granular element of the system’s implementation


SOA Design Principles

Course-GrainedInterface-based DesignDiscoverableSingle InstanceLoosely CoupledAsynchronous


Patterns for SOA…

SOA-design is often done using the following integration and orchestration architecture patterns:

Value-ObjectProxyFacadeBusiness Delegate (perhaps with factory)AdapterLayer

We will talk about these in a later lecture…

Documents

CS 575: Software Designbmitchell/course/cs575/introduction.pdf · several entrance tests prior to ... AntiPatterns are a natural extension to design patterns AntiPatterns bridge the