october 26, 2006architectural design, ecen 50331 architectural design architecture business cycle...

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


Overview




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


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


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)


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


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


Customer & End User

Developing Organization

Technical Environment

Architect’s ExperienceRequirements (Qualities)


Architecture

Archi

System


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


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.


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.



ECEN 5543 / CSCI 5548 SW Eng of Standalone Programs

University of Colorado, Boulder


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


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


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:


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


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


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


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


(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


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)


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?


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?


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


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.


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


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?

october 26, 2006architectural design, ecen 50331 architectural design architecture business cycle...

Documents