October 26, 2006 Architectural Design, ECEN 5033 1
Architectural Design
Architecture Business Cycle
Design for Maintainability
ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs, University of Colorado, Boulder
October 26, 2006 Architectural Design, ECEN 5033 2
Overview
Architecture Business Cycle
Design for Maintainability
October 26, 2006 Architectural Design, ECEN 5033 3
CUSTOMERpays for the development or purchasespecifies requirements that ensure usability (we hope) to the end usermay be more concerned with cost than usability if a compromise must be made
END USERSuse itmany different categories (see operational profiles): input givers, administrators, output receiversAcceptability involves
- behavior - platform compatibility- performance - memory utilization- reliability - network usage- availability - security- ease of modification - interoperability with other systems
October 26, 2006 Architectural Design, ECEN 5033 4
Developing Organization
Immediate businessexisting architectures and productsproposed system may be “next” in a product family so cost estimates assume high degree of reuse
Long-term businessdesire an infrastructure to pursue strategic goalsthis product seen as the way to fund that
Organizational structureFor example, lack of certain expertise may require design that allows a subsystem to be subcontracted4 strong personalities = 4 major componentsOr ... groups responsible for maintaining individual portions of the product family want the next generation product to require those groups
October 26, 2006 Architectural Design, ECEN 5033 5
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 changedIf a prior experience was a disaster, hard to muster the courage to try it againArchitectural choices may also come from
the architect’s education and trainingexposure to successful stylesexposure to systems that worked well or didn’tdesire to experiment (heh-heh)
October 26, 2006 Architectural Design, ECEN 5033 6
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!) includeindustry standard practices
software engineering techniques prevalent in the architect’s professional community
October 26, 2006 Architectural Design, ECEN 5033 7
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
October 26, 2006 Architectural Design, ECEN 5033 8
Customer & End User
Developing Organization
Technical Environment
Architect’s ExperienceRequirements (Qualities)
Architecture Business Cycle
Architecture
Archi
System
October 26, 2006 Architectural Design, ECEN 5033 9
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
October 26, 2006 Architectural Design, ECEN 5033 10
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.
October 26, 2006 Architectural Design, ECEN 5033 11
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, 2nd 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.
October 26, 2006 Architectural Design, ECEN 5033 12
Design for Maintainability
ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs
University of Colorado, Boulder
October 26, 2006 Architectural Design, ECEN 5033 13
When do you review an architecture?
Require-ments elicitation and analysis
System Test Planning
Architec-ture
fea-ture chunk-ing into pro-posed incre-ments
Increment1
Req
Tests
Des
Rev
Code
Test
Integ
Increment2
Req
Tests
Des
Rev
Code
Test
Integ
IncrementI
Req
Tests
Des
Rev
Code
Test
Integ
Increment
Req
Tests
Des
Rev
Code
Test
IntegTest Test Test Test
RELEASE
... ...Time
October 26, 2006 Architectural Design, ECEN 5033 14
What is maintenance?
Development with intermittent releasesContinues incrementally
New features
Enhanced features
Fault corrections
Hardware design fault workarounds
Designing for maintainability is also designing for ease of development
October 26, 2006 Architectural Design, ECEN 5033 15
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:
October 26, 2006 Architectural Design, ECEN 5033 16
Elements of Good Design - 11. a mind well-educated in design principles2. 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
October 26, 2006 Architectural Design, ECEN 5033 17
Design as Community
Software objects people with
responsibilities who collaborate with others
to get work done
An effective design is a community of collaborating responsible objects
October 26, 2006 Architectural Design, ECEN 5033 18
Representing community
Interaction diagramssequence diagrams
collaboration diagrams
Depicts collaborations
Allows one to consider responsibilities realized as methods
Fundamental principles guide choices about assigning responsibilities
Appropriate assignments last
October 26, 2006 Architectural Design, ECEN 5033 19
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
October 26, 2006 Architectural Design, ECEN 5033 20
(Information) ExpertAssign responsibility to the class that has the information necessary to fulfill the responsibilityObjects do things related to the information they haveFulfillment of a responsibility can require info spread across different classes
partial experts collaboratethey interact via messages to share the work
Keep app logic in domain layer, database logic in database layer – don’t intermingle system concerns
October 26, 2006 Architectural Design, ECEN 5033 21
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)
October 26, 2006 Architectural Design, ECEN 5033 22
CohesionBasic software qualityHow functionally related are the operations of a software element?Occurs naturally in hardware components; must be designed in software componentsKeeps objects focused, understandable, and manageable.Consider relationship to Low CouplingAssign responsibilities to keep cohesion highWHY?
October 26, 2006 Architectural Design, ECEN 5033 23
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?
October 26, 2006 Architectural Design, ECEN 5033 24
Pure FabricationWhat 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
October 26, 2006 Architectural Design, ECEN 5033 25
Pure Fab - continuedExample is SaleLarge number of supporting database-oriented operations, none related to the concept of sale-nessSale 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.
October 26, 2006 Architectural Design, ECEN 5033 26
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