DESIGNING ARCHITECTURECHAPTER 4

BUILDING ANALOGY

SIMPLY HAVING A SET OF POWER TOOLS AND A LOFTY VISION FOR A SKYSCRAPER IS NOT ADEQUATE FOR CREATING A FIFTY-STORY BUILDING WHICH EFFECTIVELY INTEGRATES WITH A CITY'S ELECTRICAL, WATER, DATA, AND WASTEWATER INFRASTRUCTURES.

GOAL OF THE CHAPTER: EXAMINE A VARIETY OF APPROACHES TO DESIGNING SOFTWARE

SYSTEMS• BASICS OF DESIGN PROCESS• FOUNDATIONAL CONCEPTUAL

TOOLS• REFINED EXPERIENCE• DOMAIN-SPECIFIC SOFTWARE

ARCHITECTURES• ARCHITECTURAL PATTERNS

AND STYLES• DESIGN DISCOVERY

THE DESIGN PROCESSSOFTWARE DESIGN CAN PROCEED IN THE SAME GENERAL MANNER OF ARCHITECTURAL OR ENGINEERING DESIGN WHICH HAS THESE FOUR STAGES: 1. FEASIBILITY STAGE - IDENTIFYING A SET OF FEASIBILITY CONCEPTS 2. PRELIMINARY DESIGN STAGE - DEVELOPMENT OF ENGINEERING

DESCRIPTIONS OF THE CONCEPT 3. DETAILED DESIGN STAGE - DEVELOPMENT OF ENGINEERING DESCRIPTIONS

OF THE CONCEPT 4. PLANNING STAGE - EVALUATING AND ALTERING THE CONCEPT TO SUIT THE

REQUIREMENTS OF PRODUCTION, DISTRIBUTION, CONSUMPTION AND

PRODUCT RETIREMENT

THE DESIGN PROCESSTHIS APPROACH TO DESIGN IS COMPLETELY CONSISTENT WITH COMMON, BROADER NOTIONS OF SOFTWARE ENGINEERING PROCESSES, SUCH AS THE WATERFALL AND SPIRAL METHODS OF DEVELOPMENT.SUCH UNIVERSAL USE INDICATES THAT IT IS A VERY EFFECTIVE STRATEGY IN MANY SITUATIONS.IT IS IMPORTANT TO NOTE THAT THIS IS NOT THE ONLY APPROACH EVEN THOUGH IT IS PERVASIVE IN THE SOFTWARE DEVELOPMENT WORLD.THIS IS IMPORTANT BECAUSE THE STANDARD APPROACH DOES NOT ALWAYS WORK.

CONDITIONS UNDER WHICH THE STANDARD PROCESS MAY NOT WORK

THE SUCCESS OF THIS APPROACH IS PREDICATED ON THE SUCCESS OF THE FIRST STEP.

IF THE DESIGNER IS UNABLE TO PRODUCE A SET OF FEASIBILITY CONCEPTS, PROGRESS STOPS.

STEP TWO IS HISTORICALLY DONE BY ONE PERSON, BUT AS PROJECTS GROW IN SIZE THIS WILL BECOME AN ISSUE.

HAVING A TEAM DO THIS STEP CREATES ITS OWN SET OF ISSUES.

AS COMPLEXITY INCREASES, OR THE EXPERIENCE OF THE DESIGNER IS NOT SUFFICIENT FOR THE CHALLENGE,

ALTERNATE APPROACHES TO THE DESIGN PROCESS MUST BE ADOPTED

THESE ARE SOME ALTERNATE DESIGN STRATEGIES:• STANDARD – DESCRIBED EARLIER.• CYCLIC - AS PROBLEMS OR INFEASIBLE APPROACHES ARE IDENTIFIED IN STAGES

2-4 OF THE STANDARD MODEL, THE PROCESS REVERTS TO AN EARLIER STAGE.• PARALLEL - AFTER STAGE ONE OF THE STANDARD MODEL, INDEPENDENT

ALTERNATIVES ARE EXPLORED IN PARALLEL.• ADAPTIVE - THE DESIGN STRATEGY TO FOLLOW IN THE NEXT STAGE OF THE

DESIGN ACTIVITY IS DECIDED AT THE END OF A GIVEN STAGE. "LAY TRACK AS YOU GO."

• INCREMENTAL - DESIGN AT EACH STAGE OF DEVELOPMENT IS TREATED AS A TASK OF INCREMENTALLY IMPROVING WHATEVER DESIGN OR PREVIOUS PRODUCT EXISTS AFTER A PRECEDING STAGE.

ARCHITECTURAL CONCEPTIONFEASIBILITY STAGE

IDENTIFYING A FEASIBLE SET OF "ALTERNATIVE ARRANGEMENTS FOR THE DESIGN AS A WHOLE," CHOOSING ONE OF THOSE ARRANGEMENTS, AND THEN PROCEEDING TO REFINE AND ELABORATE IT.THE STANDARD APPROACH DOES NOT TELL US HOW TO IDENTIFY THAT SET OF VIABLE ARRANGEMENTS.A SIMPLE ANSWER IS TO "APPLY THE FUNDAMENTAL DESIGN TOOLS OF ENGINEERING: ABSTRACTION AND MODULARITY.“ANOTHER SIMPLE ANSWER IS TO SAY "INSPIRATION.“A COMMON, EFFECTIVE, AND APPROPRIATE ANSWER IS APPLYING EXPERIENCE.

ARCHITECTURAL CONCEPTIONFUNDAMENTAL CONCEPTUAL TOOLS

• SEPARATION OF CONCERNS• ABSTRACTION• MODULARITY• "FIRST PRINCIPLES OF SOFTWARE ENGINEERING,"

SUCH AS ANTICIPATION OF CHANGE AND DESIGN FOR GENERALITY.

ABSTRACTION AND THE SIMPLE MACHINES

ABSTRACTION IS USUALLY SEEN AS A PROCESS THAT MOVES UPWARD FROM DETAILS TO SUMMARIZING CONCEPTS.IN DESIGN, IT USUALLY MOVES DOWNWARD: A SET OF CONCEPTS IS CHOSEN TO ALLOW DISCUSSION OF AN IDEA--AN ARRANGEMENT OF ABSTRACT PARTS THAT CONSTITUTES A SOLUTION, THOUGH STILL AT A HIGH LEVEL.

ABSTRACTION AND THE SIMPLE MACHINESTHE DESIGN THEN MOVES FURTHER DOWNWARD AS THE CONCEPTS OF ABSTRACTION ARE REIFIED (CREATED OR MADE REAL) INTO MORE CONCRETE STRUCTURES--A MORE COMPLEX WHOLE.ULTIMATELY THE REIFICATION PROCESS ENDS WITH THE PRODUCTION OF SOURCE CODE.ABSTRACTION IS OFTEN USED BECAUSE THE INTENT IS TO CREATE SOURCE CODE FOR WHICH ABSTRACTION IS AN ACCURATE AND USEFUL CHARACTERIZATION.

ABSTRACTION AND THE SIMPLE MACHINES

THE GOAL HERE IS TO TURN A COMPLEX SYSTEM INTO A "SIMPLE MACHINE:" A SIMPLE DESCRIPTION TO GET A BETTER UNDERSTANDING OF THE PROBLEM AND TO PROVIDE A PLAUSIBLE FIRST CONCEPTION OF HOW AN APPLICATION MIGHT BE BUILT.

SEPARATION OF CONCERNS

THE SUBDIVISION OF A PROBLEM INTO INDEPENDENT PARTS.

FOR INSTANCE, THE VISUAL INTERFACE THE CUSTOMER SEES AT A BANK'S ATM IS INDEPENDENT FROM THE LOGIC USED TO CONTROL OPERATION ON

THAT CUSTOMER'S ACCOUNTS.

SEPARATION OF CONCERNSDIFFICULTIES ARISE WHEN ISSUES ARE EITHER ACTUALLY OR APPARENTLY INTERTWINED.FOR EXAMPLE, A COMMON WORD SUCH AS "ACCOUNT" MAY BE USED TO DESCRIBE WHAT ARE DIFFERENT ENTITIES IN DIFFERENT PARTS OF AN APPLICATION.IN OTHER CASES, CONCEPTS MAY BE INTERTWINED BECAUSE OF SOLUTION EFFICIENCY.FOR EXAMPLE, THE PRESENCE OF NUMERIC KEYS IN USER RECORDS MAY SIMPLY REFLECT PRIOR DATABASE IMPLEMENTATION STRATEGIES AND MAY NOT BE INTRINSIC INFORMATION ABOUT THE USER.

SEPARATION OF CONCERNS

SEPARATION OF CONCERNS FREQUENTLY INVOLVES MANY TRADEOFFS: TOTAL INDEPENDENCE OF

CONCEPTS MAY NOT BE POSSIBLE.

THE DESIGNER MUST ASSESS PERFORMANCE COSTS, APPEARANCE, OR FUNCTIONAL TRADE-OFFS BETWEEN

COMPETING CONCEPTIONS.

THE GRAND TOOL: REFINED EXPERIENCETHIS SECTION IS ABOUT SOMETHING THAT IS COMPLETELY INTUITIVE AND MOSTLY GOES WITHOUT SAYING: EXPERIENCE LEADS TO BETTER DESIGN.DESIGN EXPERIENCE SUCCESSES AND FAILURES CAN AND WILL GUIDE YOU IN NEW PROJECTS.EXPERIENCE MUST BE REFLECTED UPON AND REFINED TO UNDERSTAND THE CENTRAL ISSUES AND LESSONS FROM PRIOR WORK.THIS APPLIES NOT ONLY TO YOUR OWN EXPERIENCE, BUT ALSO THAT OF OTHERS.THERE IS NO VIRTUE IN REINVENTING WHEELS, BROKEN OR OTHERWISE.APPLYING ESTABLISHED APPROACHES IS NOT AN ENTIRELY RISK FREE STRATEGY, HOWEVER.ONCE ONE HAS A FAVORITE HAMMER, EVERYTHING STARTS TO LOOK LIKE A NAIL.

REFINED EXPERIENCE IN ACTION: STYLES AND ARCHITECTURAL PATTERNS

STYLES ARE DESIGNED TO CAPTURE KNOWLEDGE OF EFFECTIVE DESIGNS FOR ACHIEVING SPECIFIED GOALS WITHIN A PARTICULAR APPLICATION CONTEXT.

USING A BUILDING ANALOGY, THE GOAL MIGHT BE PROVIDING A HOUSE FOR A SINGLE FAMILY IN THE IN A MEDITERRANEAN CLIMATE USING STONE AND TILE AS PRINCIPAL BUILDING MATERIALS. THE APPROPRIATE STYLE MIGHT BE A SINGLE-STORY VILLA.

REFINED EXPERIENCE IN ACTION: STYLES AND ARCHITECTURAL PATTERNS

FOR SOFTWARE, THE GOAL MIGHT BE PROVIDING A SECURE INSTANT MESSAGING SYSTEM TO OPERATE BETWEEN REMOTE SITES OF A GLOBAL COMPANY.THE STYLE MIGHT BE CLIENT-SERVER.AGAIN, USING A BUILDING ANALOGY, ONE CAN CHARACTERIZE A PATTERN FOR DETERMINING THE APPROPRIATE OVERHANG OF A TILED ROOF OVER AN ENTRYWAY.SIMILARLY, ONE CAN CHARACTERIZE A PROVISION OF ELEVATOR SERVICE IN A 90-STORY SKYSCRAPER.PATTERNS AND STYLES HAVE BEEN DEVELOPED FOR SMALL AND LARGE, COMPLEX APPLICATIONS.

DOMAIN SPECIFIC SOFTWARE ARCHITECTURES

1. REFERENCE ARCHITECTURE FOR AN APPLICATION DOMAIN.

2. A LIBRARY OF REUSABLE SOFTWARE COMPONENTS.3. A METHOD OF CHOOSING AND CONFIGURING

COMPONENTS TO WORK WITHIN AN INSTANCE OF THE REFERENCE ARCHITECTURE.

AGAIN WITH THE BUILDING ANALOGIES

DSSAS ARE AKIN TO THE GENERIC DESIGN OF TRACT HOUSES.THE HOMES ARE SIMILAR BUT CAN HAVE DIFFERENT OPTIONS.THE DIFFICULTY WITH DSSAS IS THAT THEY ARE SPECIALIZED FOR A PARTICULAR DOMAIN AND CANNOT BE ADAPTED EASILY.DSSAS ARE COMMON IN INDUSTRY.

ARCHITECTURAL PATTERNSMUCH LIKE DSSAS, BUT APPLIED IN A MUCH NARROWER SCOPE.DEFINITION FROM CHAPTER 3: A NAMED COLLECTION OF ARCHITECTURAL DESIGN DECISIONS THAT ARE APPLICABLE TO A RECURRING DESIGN PROBLEM, PARAMETERIZED TO ACCOUNT FOR DIFFERENT SOFTWARE DEVELOPMENT CONTEXTS IN WHICH THAT PROBLEM APPEARS.

INTRODUCTION TO STYLES

AN ARCHITECTURAL STYLE IS A NAMED COLLECTION OF ARCHITECTURAL DESIGN DECISIONS THAT (1) ARE APPLICABLE IN A GIVEN DEVELOPMENT CONTEXT, (2) CONSTRAIN ARCHITECTURAL DESIGN DECISIONS THAT ARE SPECIFIC TO A PARTICULAR SYSTEM WITHIN THAT CONTEXT, AND (3) ELICIT BENEFICIAL QUALITIES IN EACH RESULTING SYSTEM.