![[Serializable][AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class, AllowMultiple = false, Inherited = false)][MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]publicclassNotifyPropertyChangedAttribute : CompoundAspect{publicintAspectPriority { get; set; }publicoverridevoidProvideAspects(object element, LaosReflectionAspectCollection collection){Typetype = (Type)element;collection.AddAspect(type, newPropertyChangedAspect { AspectPriority = AspectPriority });foreach (PropertyInfopropertyInfointype.GetProperties(BindingFlags.Public | BindingFlags.Instance) .Where(pi => pi.GetGetMethod() != null && pi.GetSetMethod() != null)) {collection.AddAspect(propertyInfo.GetSetMethod(),newNotifyPropertyChangedAspect(propertyInfo.Name, propertyInfo.PropertyType,propertyInfo.DeclaringType) { AspectPriority = AspectPriority }); } }}](https://image.slidesharecdn.com/architectureinthesmall-091022161151-phpapp01/85/Architecture-In-The-Small-44-320.jpg)
Uploaded byRichard Banks
Architecture In The Small
The document discusses the role of architects in software development, emphasizing the importance of communication and technical leadership in achieving design goals. It identifies common project failure causes related to architecture, such as unrealistic goals and poor communication, and suggests that architects should actively code to demonstrate and validate design choices. Key takeaways include creating clean, maintainable code and avoiding complexity while addressing essential software qualities like usability and scalability.
Architecture In The Small
- 1. Architecture In theSmallRichard BanksPrincipal Consultant, ReadifySydney & Virtual ALT.NET Groupshttp://richardsbraindump.blogspot.comrichard.banks@readify.nethttp://twitter.com/rbanks54
- 2. What Does anArchitect do?
- 3.
- 4.
- 5. Explain how to“Get There”™
- 6. Lead the WayTechnically
- 7.
- 8. The Design &Structure
- 9.
- 10.
- 12.
- 13. NSW Transit T-Card$370million10years0 to show
- 14. Westpac Rebuild (1988)$156million3 years0 to show
- 15. Not just bigprojects
- 16. Apps that can’tsupport 10 users
- 17.
- 18.
- 19. So where doesit go wrong?
- 20. Project Failure ReasonsArchitectInvolvement Has Yellow Background
- 21.
- 22.
- 23. Badly defined systemrequirements
- 24. Poor reporting ofthe project's status
- 25.
- 26. Poor communication amongcustomers, developers, and users
- 27. Use of immaturetechnology
- 28. Inability to handlethe project's complexityand Over Complexificationisationing
- 29.
- 30.
- 31.
- 32.
- 33.
- 34. Software Is DesignedTop Down
- 41. Software is BuiltBottom Up
- 44. [Serializable][AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class,AllowMultiple = false, Inherited = false)][MulticastAttributeUsage(MulticastTargets.Class, AllowMultiple = false)]publicclassNotifyPropertyChangedAttribute : CompoundAspect{publicintAspectPriority { get; set; }publicoverridevoidProvideAspects(object element, LaosReflectionAspectCollection collection){Typetype = (Type)element;collection.AddAspect(type, newPropertyChangedAspect { AspectPriority = AspectPriority });foreach (PropertyInfopropertyInfointype.GetProperties(BindingFlags.Public | BindingFlags.Instance) .Where(pi => pi.GetGetMethod() != null && pi.GetSetMethod() != null)) {collection.AddAspect(propertyInfo.GetSetMethod(),newNotifyPropertyChangedAspect(propertyInfo.Name, propertyInfo.PropertyType,propertyInfo.DeclaringType) { AspectPriority = AspectPriority }); } }}
- 45. Design == WhatCode== How
- 46.
- 47. It’s the Architect’sProblem
- 48.
- 49. Design & Architectcodeat the Lowest Levels toSupport High Level design goals
- 50. Architecture in theSmall
- 51. Deals with (atleast) 3 Failure Causes
- 52.
- 53. Where Architects GoWrong
- 54. Stopping Short onDesign
- 56.
- 57. Following Guidance withoutThinking(P&P)
- 58.
- 59.
- 60. Not (properly) ExplainingHowthings should be done
- 61. Not Trying OutWhat They Expect Others To Do
- 62. a.k.a.One-Directional ArchitectureOnly doingTop Down Design
- 63. Remember:The only wayto “Get There” is via code
- 64.
- 65. If you codeit you can explain it
- 66.
- 67.
- 68. Provide Examples OthersCan Follow
- 69.
- 70. Find Problems YouOverlooked
- 71.
- 72. Choice of MethodsILWeavingInterceptorsRoll your own
- 73. Choice of ToolsEntLibIoCContainerPostSharp...more
- 74. Impact on compiletimes
- 75.
- 76.
- 77. Impact on runtimeperformance
- 78.
- 79. If you’ve nevertried it...How will you prove it works?How will you show others?
- 80. Another Thing toConsider
- 81. Teams mimic theirarchitect
- 82.
- 83.
- 87.
- 88.
- 89.
- 90. Lesson: Keep CodeSimpleBut don’t be simplistic
- 91. Lesson: Small MethodsOnly20 Lines or Less
- 92.
- 93.
- 96.
- 97. Lesson: Use DomainLanguage
- 99.
- 100.
- 103. Lesson: Single LevelOf Abstraction
- 105. Lesson: Avoid the“Duh!”Experience: Captain Obvious comments indicate a poorly architected system
- 106. A Note onUnit Testing
- 107. Test Code ==Production Code
- 110.
- 111.
- 114. Lesson: Test BehaviourNot State
- 115. Lesson: Test JustOne Behaviour
- 116. What About the*ilities
- 117.
- 118. Maintainability:Destroyed in thesmallIncludes agility, flexibility, testability, etc
- 119.
- 120. Reliability:Brought down bythe small
- 121.
- 122.
- 123.
- 124. It all comesfrom what happens in the small
- 125.
- 126. Architects Are ProjectFail Points
- 127.
- 128.
- 129.
- 130.
- 131. Simple but NotSimplistic Code
- 132. Communicate via Code(notjust Diagrams)
- 133. And sweat thedetails!
- 134.
Editor's Notes
- #2 Introduction slide: this slide must be the first slide in every RDN deck. Update the following:Title of TalkPresenter NamePresenter Position