1. October 26, 2006Architectural Design, ECEN 50331 Architectural Design Architecture Business Cycle Design for Maintainability ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs, University of Colorado, Boulder

2. October 26, 2006Architectural Design, ECEN 50332 Overview Architecture Business Cycle Design for Maintainability

3. October 26, 2006Architectural Design, ECEN 50333 CUSTOMER pays for the development or purchase specifies requirements that ensure usability (we hope) to the end user may be more concerned with cost than usability if a compromise must be made END USERS use it many different categories (see operational profiles): input givers, administrators, output receivers Acceptability involves -behavior- platform compatibility -performance- memory utilization -reliability- network usage -availability- security -ease of modification- interoperability with other systems

4. October 26, 2006Architectural Design, ECEN 50334 Developing Organization Immediate business existing architectures and products proposed system may be “next” in a product family so cost estimates assume high degree of reuse Long-term business desire an infrastructure to pursue strategic goals this product seen as the way to fund that Organizational structure For example, lack of certain expertise may require design that allows a subsystem to be subcontracted 4 strong personalities = 4 major components Or... groups responsible for maintaining individual portions of the product family want the next generation product to require those groups

5. October 26, 2006Architectural Design, ECEN 50335 Background and Experience of Architects If a certain approach produced good results in the past, first inclination is to try that again even if factors have changed If a prior experience was a disaster, hard to muster the courage to try it again Architectural choices may also come from the architect’s education and training exposure to successful styles exposure to systems that worked well or didn’t desire to experiment (heh-heh)

6. October 26, 2006Architectural Design, ECEN 50336 Technical Environment Special case of the architect’s background and experience The technical environment that is current (popular) when the architecture is designed will influence that architecture Might (mind you, I said might!) include industry standard practices software engineering techniques prevalent in the architect’s professional community

7. October 26, 2006Architectural Design, ECEN 50337 Ghostly influences Often not consciously understood Rarely fully articulated Critical to identify and actively engage the stakeholders to solicit their needs and expectations as early as possible discover constraints and additional requirements avoid false starts by managing expectations and negotiating priorities Vision document helps to reveal and engage Architectural reviews also engage Iterative development helps to engage

8. October 26, 2006Architectural Design, ECEN 50338 Customer & End User Developing Organization Technical Environment Architect’s Experience Requirements (Qualities) Architecture Business Cycle Architecture Archi System

9. October 26, 2006Architectural Design, ECEN 50339 How does the architecture affect... the structure of the developing organization the enterprise goals customer requirements for the next system the architect’s experience that influences next system the technical environment, the software engineering culture

10. October 26, 2006Architectural Design, ECEN 503310 Bibliography Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, Addison Wesley, ISBN 0- 201-19930-0 – includes several case studies and the original chapters on architecture analysis that our text uses in chapter 32. Software Engineering Concepts, Richard Fairley, McGraw-Hill, ISBN 0-07-019902-7 – excellent, compact compendium of historical software engineering.

11. October 26, 2006Architectural Design, ECEN 503311 Bibliography (cont.) Pattern-Oriented Software Architecture, A System of Patterns, Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Wiley & Sons, 1996, ISBN 0 471 95869 7 – often referred to as the POSA book. Object-Oriented Software Construction, 2 nd edition, Bertrand Meyer, Prentice Hall PTR, 1997, ISBN 0-13-629155-4 – excellent sections on the criteria of object orientation and how to get there; well (and humorously) written and thorough. “Recommended Best Industrial Practice for Software Architecture Evaluation.” G. Abowd, L. Bass, P. Clements, R. Kazman, L. Northrop, and A. Zaremski., SEI, Carnegie Mellon University, Technical Report CMU/SEI-96-TR-025, 1996.

12. October 26, 2006Architectural Design, ECEN 503312 Design for Maintainability ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs University of Colorado, Boulder

13. October 26, 2006Architectural Design, ECEN 503313 When do you review an architecture? Require- ments elicitation and analysis System Test Planning Archi tec- ture fea- ture chunk -ing into pro- posed incre- ments Incre ment1 Req Tests Des Rev Code Test Integ Incre ment2 Req Tests Des Rev Code Test Integ Incre mentI Req Tests Des Rev Code Test Integ Incre ment Req Tests Des Rev Code Test Integ Test RELEASE... Time

14. October 26, 2006Architectural Design, ECEN 503314 What is maintenance? Development with intermittent releases Continues incrementally New features Enhanced features Fault corrections Hardware design fault workarounds Designing for maintainability is also designing for ease of development

15. October 26, 2006Architectural Design, ECEN 503315 What is Maintainability? Maintainability – “… the measures taken during development, design and installation of a manufactured product that reduce required maintenance, man-hours, tools, logistic cost, skill levels, and facilities” (Dhillon, 1999, p.1) In software, what is reduced is the people- time it takes to:

16. October 26, 2006Architectural Design, ECEN 503316 Elements of Good Design - 1 1.a mind well-educated in design principles 2.responsibility-driven design obligations of an object in terms of its role Doing  something itself  initiating action in others  controlling or coordinating activities Knowing  about private encapsulated data  about related objects  about things it can derive or calculate

17. October 26, 2006Architectural Design, ECEN 503317 Design as Community Software objectspeople with responsibilities who collaborate with others to get work done An effective design is a community of collaborating responsible objects

18. October 26, 2006Architectural Design, ECEN 503318 Representing community Interaction diagrams sequence diagrams collaboration diagrams Depicts collaborations Allows one to consider responsibilities realized as methods Fundamental principles guide choices about assigning responsibilities Appropriate assignments last

19. October 26, 2006Architectural Design, ECEN 503319 How to evaluate alternative assignments Information Expert – a responsibility needs information to be fulfilled Supports low coupling Find the object that has most of the information required for the responsibility; assign it there Low Coupling – If there is dependency, when the depended-upon changes, the dependent may be affected. Low coupling reduces the impact of changes. So work for low coupling at interface points of instability, where change is likely. Reduces time, effort, and defects when modifying

20. October 26, 2006Architectural Design, ECEN 503320 (Information) Expert Assign responsibility to the class that has the information necessary to fulfill the responsibility Objects do things related to the information they have Fulfillment of a responsibility can require info spread across different classes partial experts collaborate they interact via messages to share the work Keep app logic in domain layer, database logic in database layer – don’t intermingle system concerns

21. October 26, 2006Architectural Design, ECEN 503321 Controller mouse click UI Domain Controller What first object after or beyond the UI layer should receive the message from the UI layer? EITHER: Represents the overall “system” or a device that the software is running within or a major subsystem (facade controller) OR Represents a use case scenario within which the system operation occurs (session controller)

22. October 26, 2006Architectural Design, ECEN 503322 Cohesion Basic software quality How functionally related are the operations of a software element? Occurs naturally in hardware components; must be designed in software components Keeps objects focused, understandable, and manageable. Consider relationship to Low Coupling Assign responsibilities to keep cohesion high WHY?

23. October 26, 2006Architectural Design, ECEN 503323 Creator General principle for the assignment of creation responsibilities, a very common task. Design can support low coupling, increased clarity, encapsulation, and reusability. What B do we look for to be a creator of A objects: prefer a class B which aggregates or contains class A. Why does this contribute to maintainability?

24. October 26, 2006Architectural Design, ECEN 503324 Pure Fabrication What object should have the responsibility when you do not want to violate high cohesion and low coupling (or other goals) but solutions offered by Expert and others are not appropriate? Assign a highly cohesive set of responsibilities to an artifical or convenience class that does not represent a problem domain concept. This class is a fabrication

25. October 26, 2006Architectural Design, ECEN 503325 Pure Fab - continued Example is Sale Large number of supporting database- oriented operations, none related to the concept of sale-ness Sale class has to be coupled to the relational database interface so its coupling goes up. Saving objects in a rel db is a very general task for which many classes need support. Placing these responsibilities in Sale is not likely to be reusable.

26. October 26, 2006Architectural Design, ECEN 503326 Pure Fab - continued Create a new class solely for saving objects in some kind of persistent storage medium such as a relational db Call it PersistentStorage It is an understandable concept but not something in the domain model Fabricated for the convenience of the software developer

27. October 26, 2006Architectural Design, ECEN 503327 Modular Design Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules Impact on maintainability?