Your SlideShare is downloading. ×
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Elevator pitch architecture design
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Elevator pitch architecture design

1,390

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,390
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Why and how should we testsoftware architecture andsoftware design?Zarko Acimovic
  • 2. Software Defects PotentialsAs an example for function point measure Win 7 has ~100K Function Points, Microsoft Word has~5K Function Points. The technology assumptions underlying below table assume CMMI level 1and a traditional waterfall development method.Source: Chapter 2. Estimating and Measuring Software Quality. The Economics of SoftwareQuality, ISBN: 9780132564762 , Pages 40, 41, Capers Jones, Olivier Bonsignourhttp://www.amazon.com/Economics-Software-Quality-Capers-Jones/dp/0132582201http://www.informit.com/store/product.aspx?isbn=0132582201 Defects per Function Point Percent of Total DefectsRequirement Defects 1.15 9.58%Architectural Defects 0.25 2.08%Design Defects 1.50 12.50%Coding Defects 2.00 16.67%Test Plan and Test Case Defects 1.85 15.42%User Documentation Defects 0.75 6.25%Database Defects 2.75 22.92%Website Defects 1.75 14.58%TOTAL 12.00 100.00%
  • 3. ms Te te chSys n ic DoD Architecture al Operational Framework Overview Alessio Mosto May, 2004 Source: http://www.disi.unige.it/person/ReggioG/ISII04WWW/DODAF.ppt
  • 4. Architecture Definition “The structure of components, their relationships, and the principles and guidelines governing their design and evolution over time.” DoD Integrated Architecture Panel, 1995, based on IEEE STD 610.12 “An 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 STD 1471-2000Alessio Mosto DoD Architectural Framework 2
  • 5. Architecture vs. Design System Architecture is used to:  Make buy decisions  Discriminate between options  “Discover” the true requirements  Drive one or more systems to a common “use” or purpose System Design is used to:  Develop system components  Build the system  Understand configuration changes as the system is modifiedAlessio Mosto DoD Architectural Framework 3
  • 6. Basic Principles - An Integrated Architecture with Three Views Activities/ Operational Tasks Operational Elements View Identifies What Needs To Be Done And Who Does It Information FlowSystems Data Flow Standards Rules Systems Technical X View X Z Y Standards View YRelates Systems and Characteristics Y Prescribes Standards and to Operational Needs X Conventions Communications Conventions Alessio Mosto DoD Architectural Framework 4
  • 7. Architecture ViewsAlessio Mosto DoD Architectural Framework 5
  • 8. Software Architecture DefectsSource: A Dissertation Presented to the Graduate School of Clemson UniversityIn Partial Fulfillment of the Requirements for the Degree Doctor of PhilosophyComputer Science by Kyungsoo Im December 2010Links http://etd.lib.clemson.edu/documents/1306855520/http://etd.lib.clemson.edu/documents/1306855520/Im_clemson_0050D_10926.pdfArchStudio and ArchLight !http://www.isr.uci.edu/projects/archstudio/whatis.html
  • 9. Software Design Defects Sourceshttp://www.cslhr.nu.edu.pk/GCCS/Spring2010/papers/Kamran.pdfhttp://www.scribd.com/doc/17402321/Software-Design-Defects-2http://www.ptidej.net/Members/mohanaou/paper/ASE06/Moha06-ASE.pdfhttp://www-etud.iro.umontreal.ca/~ptidej/yann-gael/Work/Publications/Documents/ASE06.ppt.pdf
  • 10. 6/24/2009 Software Design DefectsSoftware Design Defects Design Patterns are “good” solutions to recurring design problems ◦ Where you want to be in terms of good design Design Defects are “bad” solutions to recurring problems ◦ Where you should not find yourself in software development Design Defects lessen the quality of OO architectures and impede their evolution and their maintenancePatterns and Software Defects AntiPatterns To Err Is Human AntiPatterns provide patterns that have negative consequences on software 2 categories: development effort ◦ High-level (global) problems: AntiPatterns ◦ Reality of a good number of software projects ◦ Low-level (local) problems: Code Smells Help identifying problems in software “ deviations from specifications or expectations ◦ Bad design results from common mistakes and misunderstandings which might lead to failures in operation ” Provide common vocabulary to discuss They describe in general what not to do problems and their solutions in software Arise due to lack of knowledge and experience industry Understanding AntiPatterns provides the A good form of problem-solving approach knowledge to prevent or recover from themWell-Well-known AntiPatterns AntiPatterns Root causes AntiPatterns are all around us. They’re often ◦ Haste used as tools for social control. Good design is a product of careful study Trimming budgets, unrealistic committeements SOCIAL AntiPatterns Leads to compromises in software quality ◦ Apathy ◦ Criminal Not caring about solving known problems ◦ Narrow-mindedness ◦ Drug Addict Refusal to accept widely known solutions ◦ Laziness (Sloth) ◦ Witch Configuration management ◦ Ignorance ◦ PickPocket Failing to seek understanding ◦ Pride Not-invented-here syndrome: avoids using or buying already existing products 1
  • 11. 6/24/2009 AntiPatterns The Blob Blob (Huge Class) Describe context and causes “ Procedural-style design Describe symptoms to detect an leads to one object with a lion’s share of the AntiPattern in legacy software responsibilities while most other objects only hold Describe their consequences data or execute simple Describe a roadmap for their solution processes ” Large controller class Many fields and methods with a low cohesion In this course, we shall only cover Dependent on the data AntiPatterns related to software code stored in associated data classes The Blob The Blob Causes and Consequences Library_Main_Control Item Person Current_Catalog Title Typical CausesName Current_Item ISBNUser_ID User_ID Author ◦ Lack of proper Object-Oriented architectureItems_Out Fine_Amount PublisherFines Etc. Cost Data_In ◦ Prototype software evolves into a product… Do_Inventory() Check_Out_Item(Item) Qty … ◦ Lack of architectural enforcement Check_In_Item(Item) Add_Item(Item) Consequences Delete_Item(Item) Catalog Print_Catalog() Topic ◦ Modular continuity is compromised Sort_Catalog() Search_Catalog(Params) Inventory … ◦ Too complex for reuse and testing Print() Issue_Library_Card() ◦ Expensive to load into memory even for small Calculate_Late_Fine() operations The Blob The Blob - Solution Solution Library_Main_Control Item Avoid it Person Current_Catalog Title Name Current_Item ISBN ◦ Managers should review program design User_ID User_ID Author Items_Out Publisher regularly Fines Fine_Amount Etc. Cost … Data_In Refactor it Do_Inventory() Check_Out_Item(Item) Qty … Check_In_Item(Item) ◦ Move behavior away from the Blob Add_Item(Item) Delete_Item(Item) ◦ Construct cohesive classes: cohesive set of Print_Catalog() Catalog Topic attributes and methods are encapsulated Sort_Catalog() Search_Catalog(Params) Inventory … together Print() Issue_Library_Card() ◦ Remove far-coupling Calculate_Late_Fine() 2
  • 12. 6/24/2009 Spaghetti Code Spaghetti Code Causes and Consequences “ Ad hoc software structure makes it difficult Typical Causes to extend and optimize code.” Code with very little software structure, ◦ Inexperience with Object-Oriented design lack clarity technologies Implementation invokes a process flow ◦ Ineffective code reviews Lack of structure : no inheritance, no ◦ No initial software design reuse, no polymorphism Long methods process oriented with no Consequences parameters and low cohesion ◦ Code reuse is difficult Procedural names of classes and methods ◦ Follow-on maintenance efforts contribute to the Negligible degree of interaction between problem objects Use of global variables for processing ◦ Software reaches point of diminishing returns: the effort involved to maintain existing code exceeds the cost of developing a new “ground up” solutionpublic boolean startElement(int, XMLAttrList) if (prefix == -1) { ...throws Exception { if (!fValidating && !fNamespacesEnabled) { return false; if (elementURI != -1) { fStringPool.setURIForQName(...); •No Objects •Process Flow Spaghetti Code } } if (contentSpecType == -1 && fValidating) { } else { •Conditionals •Complexity Solution ... ... } if (elementURI == -1) { •Cannot be The best way is to prevent spaghetti code by first if (... && elementIndex != -1) { ... } ... reused thinking and then developing. To avoid: } } fStringPool.setURIForQName(.elementURI); ◦ Domain model even when it is well-understood if (DEBUG_PRINT_ATTRIBUTES) { ... if (attrIndex != -1) { ◦ OO Analysis } int index = attrList.getFirstAttr(attrIndex); if (fNamespacesEnabled) { while (index != -1) { ◦ OO Design int attName = attrList.getAttrName(index); fNamespacesScope.increaseDepth(); if (attrIndex != -1) { if (!fStringPool.equalNames(...)) { ◦ Objects should be sufficiently refined ... int index = attrList.getFirstAttr(attrIndex); if (attPrefix != fNamespacesPrefix) { When adding new features, remove code defects while (index != -1) { if (attPrefix == -1) { ... ... Write accessor functions for member variables if (fStringPool.equalNames(...)) { } ... else { Refactor code into methods } if (uri == -1) { else {...} … Remove obsolete code } } index = attrList.getNextAttr(index); fStringPool.setURIForQName(attName, uri); Rename classes, functions, data types to conform if (fElementDepth >= 0) { } } fElementDepth++; to industry standards if (fElementDepth == fElementTypeStack.length) { int prefix = ...fStringPool.getPrefixForQName(elementType); } }}} int elementURI; return contentSpecType == fCHILDRENSymbol; } Functional Decomposition Functional Decomposition Causes and Consequences One main routine that calls several other Typical Causes subroutines ◦ No use of OO concepts like inheritance or Invoked subroutines are implemented as polymorphism classes ◦ Lack of understanding of OO concepts Classes with single action such as a ◦ Lack of architecture enforcement function Consequences Attributes are private and used only ◦ Difficult to reuse inside the class ◦ Expensive to maintain The resulting code resembles a structural ◦ no way to clearly document (or explain) how the system works language like C and is incredibly complex 3
  • 13. 6/24/2009 Functional Decomposition Functional Decomposition Solution A customer loan scenario Find the original Use Cases to ascertain Adding a new customer features from user view point Updating a customers address OO reengineering process Calculating a loan to a customer Find matching OO design model Calculating the interest on a loan Combine classes which assist each other Calculating a payment schedule for a Combine classes which try to achieve the customer loan same design objective Altering a payment schedule Find similar subsystems (reuse of code)Functional Decomposition OO VersionCut-and-Cut-and-Paste Programming Cut-and- Cut-and-Paste Programming Causes and Consequences “Man, you guys work fast. Over 400,000 lines of Typical Causes code in just three weeks is outstanding progress.” ◦ Reusable code is difficult to create and organizations prefer Cut-and-Paste Programming is a short term benefits very common degenerate form of ◦ Easier to modify existing code than writing from scratch software reuse that causes maintenance nightmares. ◦ Lack of abstraction in developers Less experienced programmers ◦ Lack of knowledge of tools and technologies, hence working examples are modified to create new components learn by changing code of experienced developers ◦ Lack of forward thinking Presence of several similar Consequences segments of code ◦ Software defects and bugs are replicated Creates code duplication ◦ Difficult to locate all instances of a bug Positive short-term consequences ◦ Code reviews and inspections are needlessly extended such as boosting line count metrics ◦ Excessive software maintenance costs ◦ Duplication of testing, review, bug fixing efforts 4
  • 14. 6/24/2009 Cut-and- Cut-and-Paste Programming Swiss Army Knife Solution A Swiss Army knife is a Three step approach brand of multi-function ◦ Identify Code duplication pocket knife or multi-tool. Excessively complex class ◦ Refactoring duplicates into libraries or interface components for black-box reuse Designer attempts to ◦ Configuration management : code inspection, provide for all possible uses of the class. reviews and validation efforts in future to Large number of interface avoid Cut-and-Paste Programming signatures No clear abstraction or focus of the class interface Swiss Army Knife Swiss Army Knife Causes and Consequences Solution Causes Describe a profile for the class ◦ No focused responsibility Profile documents the way to use a ◦ Class attempting to provide too much complex technology functionality Consequences Profile for an interface describe the ◦ More != Better signatures and parameter values ◦ Confusion ◦ Maintenance problems ◦ Each interface requires implementation of items on that interfaceConclusions Code Smells “If it stinks, change it” AntiPatterns provide patterns that have negative consequences on software development effort Each AntiPattern includes a solution + solution pair Hint that something has gone wrong ◦ AntiPattern Solution Generates mostly negative consequences Opportunities for improving program ◦ Refactored Solution Generates mostly positive design benefits AntiPatterns are useful for refactoring, migration, Code smells indicate the need for the upgrade, and reengineering application of a possible refactoring 5
  • 15. 6/24/2009Code Smells - Examples Code Smells – More Examples Duplicate Code Long Parameter List ◦ Duplication of bugs, tests, reviews ◦ Same (or nearly) code in multiple places ◦ Programs harder to understand ◦ Frequently the result of cut-and-paste coding ◦ Difficult to reuse and change Long Method ◦ Parameter lists should be shorter in OO ◦ OO puts premium on short methods programs than in traditional programs ◦ Long procedures always harder to understand Divergent Change Large Class ◦ Class has poor cohesion ◦ One class commonly changed in different ◦ Too many instance variables or methods means a class is ways for different reasons doing too much ◦ Some methods changed in one case ◦ Class interface does not provide consistent level of abstraction ◦ Other methods changed in anotherCode Smells – More Examples Feature Envy ◦ Method seems more interested in a class other than the one it is in ◦ Most common focus is data (lots of getter calls) Data Clumps ◦ Same data items in multiple classes ◦ Parameter lists of several methods ◦ If after deleting one from clump the rest wouldn’t make sense, a clear candidate for refactoring 6
  • 16. ArgoUML !!!
  • 17. ArgoUML Design CriticsChapter 15. The CriticsTable of Contents15.1. Introduction 15.1.1. Terminology 15.1.2. Design Issues15.2. Uncategorized15.3. Class Selection 15.3.1. Wrap DataType 15.3.2. Reduce Classes in namespace <namespace> 15.3.3. Clean Up Diagram15.4. Naming 15.4.1. Resolve Association Name Conflict 15.4.2. Revise Attribute Names to Avoid Conflict 15.4.3. Change Names or Signatures in a model element 15.4.4. Duplicate End (Role) Names for an Association 15.4.5. Role name conflicts with member 15.4.6. Choose a Name (Classes and Interfaces) 15.4.7. Name conflict in a namespace 15.4.8. Choose a Unique Name for a model element (Classes and Interfaces) 15.4.9. Choose a Name (Attributes) 15.4.10. Choose a Name (Operations) 15.4.11. Choose a Name (States) 15.4.12. Choose a Unique Name for a (State related) model element 15.4.13. Revise Name to Avoid Confusion
  • 18. 15.4.14. Choose a Legal Name 15.4.15. Change a model element to a Non-Reserved Word 15.4.16. Choose a Better Operation Name 15.4.17. Choose a Better Attribute Name 15.4.18. Capitalize Class Name 15.4.19. Revise Package Name15.5. Storage 15.5.1. Revise Attribute Names to Avoid Conflict 15.5.2. Add Instance Variables to a Class 15.5.3. Add a Constructor to a Class 15.5.4. Reduce Attributes on a Class15.6. Planned Extensions 15.6.1. Operations in Interfaces must be public 15.6.2. Interfaces may only have operations 15.6.3. Remove Reference to Specific Subclass15.7. State Machines 15.7.1. Reduce Transitions on <state> 15.7.2. Reduce States in machine <machine> 15.7.3. Add Transitions to <state> 15.7.4. Add Incoming Transitions to <model element> 15.7.5. Add Outgoing Transitions from <model element> 15.7.6. Remove Extra Initial States 15.7.7. Place an Initial State 15.7.8. Add Trigger or Guard to Transition 15.7.9. Change Join Transitions 15.7.10. Change Fork Transitions 15.7.11. Add Choice/Junction Transitions 15.7.12. Add Guard to Transition 15.7.13. Clean Up Diagram 15.7.14. Make Edge More Visible 15.7.15. Composite Association End with Multiplicity >115.8. Design Patterns
  • 19. 15.8.1. Consider using Singleton Pattern for <class> 15.8.2. Singleton Stereotype Violated in <class> 15.8.3. Nodes normally have no enclosers 15.8.4. NodeInstances normally have no enclosers 15.8.5. Components normally are inside nodes 15.8.6. ComponentInstances normally are inside nodes 15.8.7. Classes normally are inside components 15.8.8. Interfaces normally are inside components 15.8.9. Objects normally are inside components 15.8.10. LinkEnds have not the same locations 15.8.11. Set classifier (Deployment Diagram) 15.8.12. Missing return-actions 15.8.13. Missing call(send)-action 15.8.14. No Stimuli on these links 15.8.15. Set Classifier (Sequence Diagram) 15.8.16. Wrong position of these stimuli15.9. Relationships 15.9.1. Circular Association 15.9.2. Make <association> Navigable 15.9.3. Remove Navigation from Interface via <association> 15.9.4. Add Associations to <model element> 15.9.5. Remove Reference to Specific Subclass 15.9.6. Reduce Associations on <model element> 15.9.7. Make Edge More Visible15.10. Instantiation15.11. Modularity 15.11.1. Classifier not in Namespace of its Association 15.11.2. Add Elements to Package <package>15.12. Expected Usage 15.12.1. Clean Up Diagram15.13. Methods 15.13.1. Change Names or Signatures in <model element>
  • 20. 15.13.2. Class Must be Abstract 15.13.3. Add Operations to <class> 15.13.4. Reduce Operations on <model element>15.14. Code Generation 15.14.1. Change Multiple Inheritance to interfaces15.15. Stereotypes15.16. Inheritance 15.16.1. Revise Attribute Names to Avoid Conflict 15.16.2. Remove <class>s Circular Inheritance 15.16.3. Class Must be Abstract 15.16.4. Remove final keyword or remove subclasses 15.16.5. Illegal Generalization 15.16.6. Remove Unneeded Realizes from <class> 15.16.7. Define Concrete (Sub)Class 15.16.8. Define Class to Implement <interface> 15.16.9. Change Multiple Inheritance to interfaces 15.16.10. Make Edge More Visible15.17. Containment 15.17.1. Remove Circular Composition 15.17.2. Duplicate Parameter Name 15.17.3. Two Aggregate Ends (Roles) in Binary Association 15.17.4. Aggregate End (Role) in 3-way (or More) Association 15.17.5. Wrap DataType

×