CS 575: Software Design
CS 575: Software DesignIntroduction Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu1
Software DesignA software design is a precise descriptionof a system, using a variety of differentperspectives teriaBehavioralInfrastructure Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu2
Expressing A Software DesignSoftware Designs are complicated, therefore,they must be modeled Similar to an architects blueprintA model is an abstraction of the underlyingproblemDesigns should be modeled, and expressedas a series of viewsHelpful to use a modeling language such asUML Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu3
Modeling as a Design TechniqueDesigns are too complicated to develop fromscratchGood 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 modelsinto the design Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu4
Modeling as a Design TechniqueLets Build this System ionCriteriaBehavioralInfrastructureLets Start Buildingthis System Drexel University Software Engineering Research Group ntDesignDesign5
Modeling as a Design Technique ImprovedLets Build this System Frameworks,Patterns,Templates, idationCriteriaBehavioralInfrastructureIncremental RefinementLets Start Buildingthis System Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduDesignDesign6
Modeling Designs DesignDesignDesigningDesigning WithWith tandModeling Tool Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduVisualization7
UML – A modeling Notationfor DesignStructuralClass DiagramsPackaging/ImplementationPackage DiagramsComponent oralInfrastructure/Use CasesEnvironmentSequence DiagramsCollaboration DiagramsDeployment DiagramsStatechart DiagramsActivity Diagrams Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu8
Software ArchitectureAccording to Shaw and Garlan The Software Architecture of a system consists of adescription of the system elements, interactionsbetween the system elements, patterns that guidethe system elements, and constraints on therelationships between system elements. Its a more abstract view of the designIts helpful for communication and complexitymanagementProblem: There is no standard definition –see ml Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu9
The Software Architecture “Stack”Software ArchitectureSubsystem DecompositionSubsystem DependenciesSubsystem InterfacesModule/Class DecompositionsModule/Class DependenciesModule/Class InterfacesData StructuresAlgorithms Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu10
The Software Architecture “Stack”High-Level(Abstract)DesignSoftware ArchitectureSubsystem DecompositionSubsystem DependenciesSubsystem InterfacesModule/Class s DependenciesModule/Class InterfacesData StructuresAlgorithms Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu11
Why do we design A software design is not necessary for trivialsystems, but for large systems a design is essentialManage complexityValidation of delivered softwareSimplify future maintenanceA mechanism for communication between domainexperts and technical professionalsEnables VisualizationEnables project team members to work concurrently Partitioning the work effort with limited overlapExample: Concurrently developing test cases while the codeis being development Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu12
Why is design so hard Software design can’t be taught, butprinciples 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 andrequirements that support the design changeA design is like wine, it takes a long time tosee if it is good or not Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu13
mming Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu14
Software Development MethodologyA 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 anotherHelps with the project management aspectsof a software development project Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu15
Modeling Emphasis for Different dStructureTraditional/StructuredFunction Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu16
Jumpstarting Design?Starting from scratch “blank screen” is tough.Components of a design toolbox – Templates,Patterns, Reference Architectures, Frameworks,and so on Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu17
Example: Jakarta Struts PresentationFramework Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu18
Example: J2EEArchitecture j2eepatterns/Patterns/ Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu19
Example: Intercepting Filter PatternArchitectural PatternProblem: Preprocessing and post-processing of a client Webrequest and response are required When a request enters a Webapplication, it often must passseveral entrance tests prior tothe main processing stage: Has the client been authenticated? Does the client have a valid session? Is the client's IP address from a trustednetwork? 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 unobtrusivemanner is to have a simple mechanism for adding and removingprocessing components, in which each component completes aspecific filtering action. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu20
Design PatternsExample: ObserverPattern Define a one-to-manydependency betweenobjects so that whenone object changesstate, all itsdependents arenotified and updatedautomaticallyNote: Design pattern references often include samplecode in a variety of languages to illustrate how to usethe pattern. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu21
What’s good about PatternsThey solve common problems in a“proven” wayThey tend not to be implementationspecificThey tend to be classified in a commonway – context, forces, examples, etcThey embody good design principles Example: Loose Coupling Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu22
Design QualitySoftware design “quality”, as with otherideas on quality, is an elusive concept:It depends on priorities of yourcompany and the customers: fastest to implementeasiest to implementeasiest to maintain, “evolve”, portmost efficient/reliable/robust end-product. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu23
How to “Fix” A Software DesignMany times the source code is the onlyup-to-date documentation for asoftware system Must be able to recover the design to someextentMust be able to “improve” the designwhere appropriate Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu24
Improving Existing Designs - RefactoringSee Martin Fowler’s BookWhat is Refactoring: Refactoring is a technique torestructure code in a disciplined wayUsed to improve a system design in any numberof waysPattern/Template based processAutomated tools existRefactoring is a behavior preserving transformation ofthe source code Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu25
Example: Refactoring – PushDownMethodAfterBeforeBillBill setName() getAddress() send()Note: There are manyways to do this type ofrefactoring – this is justone example. setName() getAddress() #send()EBill send() Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.eduMailBill send()26
Anti-Patterns (plus Refactoring)AntiPatterns are Negative Solutions thatpresent more problems than they addressAntiPatterns are a natural extension to designpatternsAntiPatterns bridge the gap betweenarchitectural concepts and real-worldimplementations.Understanding AntiPatterns provides theknowledge to prevent or recover from them Recovery can be via RefactoringFrom: www.antipatterns.com Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu27
Antipattern Example: PoltergeistsProliferation of classes [Riel 96]Spurious classes and associations Stateless, short-lifecycle classesClasses with few responsibilitiesTransient associationsExcessive complexityUnstable analysis and design modelsAnalysis paralysisDivergent design and implementationPoor system performanceLack of system extensibilityFrom: www.antipatterns.com Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu28
Antipattern Example: PoltergeistsFrom: www.antipatterns.com Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu29
Antipattern Example: Fixing PoltergeistsRefactor to eliminate irrelevant classes Delete external classes (outside the system)Delete classes with no domain relevanceRefactor to eliminate transient “data classes”Refactor to eliminate “operation classes”Refactor other classes with short lifecycles orfew responsibilities Move into collaborating classesRegroup into cohesive larger classesFrom: www.antipatterns.com Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu30
Good Design PropertiesHierarchical: A good design should beorganized into a well-designed hierarchy ofcomponents.Modular: Separate distinct concerns(dataand processing) into distinct containers(i.e.,subsystems, modules, and/or classes).Hide implementation details and provideclean, simple interfaces for each container. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu31
Good Design PropertiesIndependent: Group similar thingstogether; limit the amount of “specialknowledge” that unrelated componentsmay share. If you change your mindabout something, the impact will belocalized. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu32
Good Design PropertiesSimple Interfaces: Endless flexibility addscomplexity. 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 toeliminate “bad options”.You can get away with “flexible interfaces” ina low-level localized setting, but the largerthe scale, the simpler the interface should be. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu33
Summary: Software DesignGood software designers areexperienced software designers Given a design, and experienced designercan tell you: What’s good, What’s Bad, and providesuggestions for improvement Patterns and Frameworks are very helpfulto software designersGood software designs are based ongood design principles Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu34
Demystifying SOAService-Oriented architecture is the latest“buzz” in the information technology andenterprise application domainsThere is a lot of hype, buzzwording andmisconception around SOAWe will place a good bit of emphasis in thiscourse examining at SOA to try to understandits pro’s and con’s from an applicationarchitecture and design perspective. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu35
SOA – Its an Architecture, Design andInstantiation ApproachUnderstanding SOA requires one toanswer the following questions: What is a service oriented architecture?What is a service?How do I design an application thatadheres to a SOA?How do I implement an applicationdesigned using SOA principles? Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu36
Traditional versus SOA applications – aline and box view Traditional ApplicationSOA ApplicationApplication ns designed in conjunction with an SOA style are easier to design,implement, maintain and extend due to the loose coupling of componentsthat reside in different services The pieces (services) in an SOA are designed with a courser granularity than andesign based on traditional components, making the system simpler to deal withThe messaging interfaces between the services in an SOA have structure andsemantics allowing them to be intelligently routed and provisioned based onapplication-specified policies Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu37
What is a service?Service (also application service): Anapplication function that (a) within eachrequest, encompasses a complete parcel ofwork (business or technical), (b) may stand onits own or be part of a larger set of functionsthat constitute a larger service but its scope issuch that each request leaves the system in along-term steady state, (c) is designed for andprovides a network-accessible interface and(d) is designed to receive requests from anysource, making no assumptions as to thefunctional correctness (syntactic or semantic)of an incoming request. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu38
What is a service? – Technically Service ProvidedInterfaceC1C2RequiredInterfaceC3Service boundaries are explicit Service invocation based on message passing and notmethod invocationServices are autonomous Services can be deployed and/or extended independently ofthe service consumers (i.e., applications)Services can be developed in any language since the bindingis in the form of an encoded message in a standard format Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu39
What is a service? – Technically Service ProvidedInterfaceC1C2RequiredInterfaceC3Services share schema and contract, not class Services advertise a contract that describes thestructure (schema) of messages it can sendand/or receive as well as some degree of orderingconstraints over those messages.Interfaces are defined in terms of a schema andnot binary classesExample: WSDL in Web Services Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu40
What is a service? – Technically Service ProvidedInterfaceC1C2RequiredInterfaceC3Service compatibility is determined based on policy Due to the tightly coupled nature of OO and Component designs,they assume that structural compatibility implies semanticcompatibilityStructural compatibility in SOA is based on contract and schemaand can be validated (if not enforced) by machine-basedtechniques (such as packet-sniffing, validating firewalls). Semanticcompatibility is based on explicit statements of capabilities andrequirements in the form of policy.Policy expressions indicate which conditions and guarantees (calledassertions) must hold true to enable the normal operation of theservice. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu41
Why SOA – Another Layer of AbstractionOO abstractions were introduced to deal withthe complexity of managing functionsindependent of dataCBD abstractions were introduced to dealwith the complexity of distribution,packaging, and deploymentSOA abstractions were introduced to createthe notion of a network-aware, singleinstance component that can participate in aboth synchronous and asynchronous businessprocess Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu42
Activates to consider when designing anSOA [ref: ew/full/55441]SOA separates the concerns of the service consumer andthe service provider. Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu43
Logical Layering for SOA[ref: ew/full/55441](e.g., ESB) Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu44
Services are another layerof AbstractionServices are special types of components, having a published interface thatconsists of a subset of one or more public component interfaces thatcollectively defines the service boundaryComponents are built from a collection of objects where the emphasis is oncreating a deployable package that enables the component to execute in amanaged 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 Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu45
SOA Design PrinciplesCourse-GrainedInterface-based DesignDiscoverableSingle InstanceLoosely CoupledAsynchronous Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu46
Patterns for SOA SOA-design is often done using the followingintegration and orchestration architecturepatterns: Value-ObjectProxyFacadeBusiness Delegate (perhaps with factory)AdapterLayerWe will talk about these in a later lecture Drexel University Software Engineering Research Group (SERG)http://serg.cs.drexel.edu47
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
swillowbee@comcast.net 575 -524 9395 Cindy Cook cindy77lou@yahoo.com 575-640-0860 NARFE-FEEA: Roy Willoughby rswillowbee@comcast.net 575-524-9395 Program Chair: Donna Harris md.harris1@comcast.net 575-382-9070 Records Officer: Carol Main csmain7@gmail.com 575-382-7686 Service Officer: Jim Kielty 575 -523 6044
for installing the GTO/PRO SW-4200 with the GTO/PRO SW-4000 in a dual application FOR PROFESSIONAL INSTALLATION ONLY! 3121 Hartsfield Road Tallahassee, Florida, USA 32303 Telephone GTO Sales: 1-800-543-GATE (4283) or (850) 575-0176 Fax (850) 575-8912 or GTO Technical Service: 1-800-543-1236 or (850) 575-4144 Fax (850)575-8950 www .
Toyota Land Cruiser LC80 1FZ-FE Turbo Kit T70 Turbo and 50mm 10 PSI Wastegate, Capable of 500 HP www.cxracing.com 1627 Chico Ave, South El Monte, CA 91733 Tel: sales-(626) 575-3288, fax (626) 575-9228, sales@cxracing.com, Tech--(626) 575-3288, support@cxracing.com CXRACING CXRACING CXRACING CXRACING CXRACING CXRACING CXRACING
Las Cruces, NM 88005 Telephone (575)526-2517/Fax (575)524-0544 Preschool (575)526-3585 . 2 . Welcome to Holy Cross School and St. Mary’s High. Our 2017-2018 student handbook contains important information regarding the po
Clovis, NM 88101 (575) 769-2141 LAS CRUCES DONA ANA COUNTY GENERAL ACUTE CARE HOSPITAL Memorial Medical Center 2450 S Telshor Blvd Las Cruces, NM 88011 (575) 522-8641 Mountainview Regional Hosp 4311 E Lohman Ave Las Cruces, NM 88011 (575) 556-7600 LONG-TERM ACUTE CARE HOSPITAL (LTACH) Advanced Care Hospital of So NM 4451 E Lohman Ave Las Cruces .
575 Series Pulse Generator Operating Manual . Version 5.6 Berkeley Nucleonics Corp. 2955 Kerner Blvd. San Rafael, CA 94901 (415) 453-9955 phone . In addition to a 30-day money back guarantee, the 575 has a two-year limited warranty from the date of delivery. This warranty covers defects in materials and
tres tipos principales de software: software de sistemas, software de aplicación y software de programación. 1.2 Tipos de software El software se clasifica en tres tipos: Software de sistema. Software de aplicación. Software de programación.
The IC Dedicated Support Software is described in Section 1.4.3.2. 1.3.1.2 Security Software The IC Dedicated Software provides Security Software that can be used by the Security IC Embedded Software. The Security Software is composed of Services Software and Crypto Library. The Services Software consists of Flash Services Software, Services .
