Upload
zubin67
View
1.053
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Citation preview
1© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
CS 575: Software Design
Introduction
2© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Software Design
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
A software design is a precise description of a system, using a variety of differentperspectives…
3© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Expressing A Software Design
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
Software Designs are complicated, therefore,they must be modeled…
4© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 system 2) Build models using precise notations
(e.g., UML) 3) Verify that the models satisfy the
requirements 4) Gradually add details to transform the
models into the design
5© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Modeling as a Design Technique
Models
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Lets Build this System…
IncrementalRefinement
DesignDesignLets Start Building this System…
6© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Modeling as a Design Technique - Improved
Models
Structural Packaging
Behavioral Infrastructure
Requirements,Test/Validation
Criteria
Lets Build this System…
Incremental Refinement
DesignDesignLets Start Building this System…
Frameworks,Patterns,Templates, etc.
7© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Designing With ModelsDesigning With Models
Modeling Designs…
DesignDesign
VeryComplicated
ToUnderstand Modeling Tool
ModelRepository
Visualization
8© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
UML – A modeling Notationfor Design
Structural Packaging/Implementation
Behavioral Infrastructure/Environment
Requirements,Test/Validation
Criteria
Use Cases
Class Diagrams
Sequence DiagramsCollaboration DiagramsStatechart DiagramsActivity Diagrams
Package DiagramsComponent Diagrams
Deployment Diagrams
9© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 design Its helpful for communication and
complexity managementProblem: There is no standard definition – see http://www.sei.cmu.edu/architecture/definitions.html
10© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
The Software Architecture “Stack”
Software Architecture
Subsystem Decomposition
Subsystem Dependencies
Subsystem Interfaces
Module/Class Decompositions
Module/Class Dependencies
Module/Class Interfaces
Data Structures
Algorithms
11© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
12© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Why do we design…
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 overlap Example: Concurrently developing test cases while
the code is being development
A software design is not necessary for trivialsystems, but for large systems a design is essential
13© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
14© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
How Humans Design...
From “Wicked Problems and Social Complexity” http://www.cognexus.org/id42.htm, Jeff Conklin
15© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Software Design (for non-trivial applications) is a “Wicked Problem”
“You don't understand the problem until you have developed a solution”
As candidate solutions are developed, new aspects of the problem are exposed, requiring the solution to be adjusted
“There is no stopping rule” There can be no “solution” without a formal definition of
the problem. Stopping happens when you run out of time, money, resources, etc.
“Solutions to wicked problems are not 'right' or 'wrong'” Can be considered “good enough”, or “not satisfactory”
16© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Software Design (for non-trivial applications) is a “Wicked Problem”
“Every wicked problem is unique and novel” There are so many factors and conditions, all embedded
in a dynamic social context, that no two wicked problems are alike, and the solutions to them will always be custom designed and fitted.
“Every solution to a wicked problem is a one shot operation”
You cannot learn about the problem without trying a solution, but each solution considered is so complex and expensive that trying more than one is not feasible
“Wicked problems have no given alternative solutions” Its a matter of creativity to devise potential solutions, and
a matter of judgement to determine which are valid
17© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Why what you learned in software engineering 101 does not work...
From Raymonde Guindon's paper “Designing the Design Process: Exploiting Opportunistic Thoughts” Top-down decomposition is problematic in
the early stages of design due to the ill-structuredness the problems considered
Opportunistic design approaches are used in practice where partial solutions are discussed as new requirements are uncovered
A top-down decomposition appears to be a special case for well-structured problems when the designer already knows the correct decomposition
18© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
DesignMethodologies
ExtremeProgramming
Waterfall
Iterative
19© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Software Development Methodology
A Methodology is: A Process
What happens over time Coupled to the Software Development Lifecycle
(SDLC) A Management Approach
What is needed to move from one step to another
Helps with the project management aspects of a software development project
20© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Modeling Emphasis for Different Design Approaches
ComponentOriented
Traditional/Structured
ObjectOriented
Data
Structure
Function
21© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Jumpstarting Design
Starting from scratch “blank screen” is tough. Components of a design toolbox – Templates, Patterns, Reference Architectures, Frameworks,and so on…
?
22© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Example: Jakarta Struts Presentation Framework
23© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Example: J2EE Architecture PatternsSource:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/
24© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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.
25© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 automaticallyNote: Design pattern references often include sample
code in a variety of languages to illustrate how to usethe pattern.
26© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
27© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 implement easiest to implement easiest to maintain, “evolve”, port most efficient/reliable/robust end-
product.
28© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 extent Must be able to “improve” the design
where appropriate
29© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Improving Existing Designs - Refactoring
See Martin Fowler’s BookWhat is Refactoring: Refactoring is a technique to
restructure code in a disciplined way Used to improve a system design in any
number of ways Pattern/Template based process Automated tools exist
Refactoring is a behavior preserving transformation ofthe source code…
30© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Example: Refactoring – PushDown Method
Bill+setName()+getAddress() …+send()
Bill+setName()+getAddress() …#send()
EBill+send()
MailBill+send()
Before After
Note: There are manyways to do this type ofrefactoring – this is justone example.
31© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
32© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
From: www.antipatterns.com
33© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Antipattern Example: Poltergeists
From: www.antipatterns.com
34© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 classesFrom: www.antipatterns.com
35© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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.
36© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Good Design Properties
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.
37© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Good Design Properties
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 use inconvenient 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.
38© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Summary: Software Design
Good 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
39© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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.
40© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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?
41© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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 with
The 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
42© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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.
43© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What is a service? – Technically…
Service boundaries are explicit Service invocation based on message passing and
not method invocation
Services are autonomous Services 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
44© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What is a service? – Technically…
Services share schema and contract, not class Services 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 classes
Example: WSDL in Web Services
ProvidedInterface
RequiredInterface
<<Service>>
C1 C2
C3
45© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
What is a service? – Technically…
Service compatibility is determined based on policy Due to the tightly coupled nature of OO and Component
designs, they assume that structural compatibility implies semantic compatibility
Structural 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 the service.
ProvidedInterface
RequiredInterface
<<Service>>
C1 C2
C3
46© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
47© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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.
48© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Logical Layering for SOA [ref: http://www.webservices.org/index.php/ws/content/view/full/55441]
(e.g
., ES
B)
49© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
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
50© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
SOA Design Principles
Course-GrainedInterface-based DesignDiscoverableSingle InstanceLoosely CoupledAsynchronous
51© Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu
Patterns for SOA…
SOA-design is often done using the following integration and orchestration architecture patterns: Value-Object Proxy Facade Business Delegate (perhaps with factory) Adapter Layer
We will talk about these in a later lecture…