软件架构和UML

1 Software Architecture and the UML Grady Booch 2 Architecting a dog house &DQ�EH�EXLOW�E\�RQH�SHUVRQ 5HTXLUHV 0LQLPDO�PRGHOLQJ 6LPSOH�SURFHVV 6LPSOH�WRROV 2 3 Architecting a house %XLOW�PRVW�HIILFLHQWO\�DQG�WLPHO\�E\�D�WHDP 5HTXLUHV 0RGHOLQJ :HOO�GHILQHG�SURFHVV 3RZHU�WRROV 4 Architecting a high rise 3 5 Early architecture Progress - Limited knowledge of theory 6 Modern architecture Progress - Advances in materials - Advances in analysis Scale - 5 times the span of the Pantheon - 3 times the height of Cheops 4 7 Modeling a house 8 Movements in civil architecture ‰ Bronze age/Egyptian (Imhotep) ‰ Grecian/Roman (Vitruvius) ‰ Byzantine/Romanesque ‰ Gothic ‰ Mannerism (Michelangelo, Palladio) ‰ Baroque ‰ Engineering/Rational/National/Romantic ‰ Art noveau ‰ Modern movement (Wright, LeCorbusier) Progress - Imitation of previous efforts - Learning from failure - Integration of other forces - Experimentation 5 9 Kinds of civil architecture ‰ Community - houses, flats and apartments, gardens, education, hospitals, religion ‰ Commerce - shops and stores, restaurants, hotels, office buildings, banks, airports ‰ Industry - industrial buildings, laboratories, farm buildings ‰ Leisure - sport, theaters and cinemas, museums Neufert Architect’s Data The Handbook of Building Types 10 Forces in civil architecture Avoiding failure - Safety factors - Redundancy - Equilibrium Compression Load Tension Load Kinds of loads - Dead loads - Live loads - Dynamic loads Any time you depart from established practice, make ten times the effort, ten times the investigation. Especially on a very large project. - LeMessuier 6 11 Shearing layers of change Site Skin Structure Services Space plan Stuff Brand, How Buildings Learn 12 Dimensions of software complexity Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance Lower technical complexity - Mostly 4GL, or component-based - Application reengineering - Interactive performance Higher management complexity - Large scale - Contractual - Many stake holders - “Projects” Lower management complexity - Small scale - Informal - Single stakeholder - “Products” Defense MIS System Defense Weapon SystemTelecom Switch CASE Tool National Air Traffic Control System Enterprise IS (Family of IS Applications) Commercial Compiler Business Spreadsheet IS Application Distributed Objects (Order Entry) Small Scientific Simulation Large-Scale Organization/Entity Simulation An average software project: - 5-10 people - 10-15 month duration - 3-5 external interfaces - Some unknowns & risks Embedded Automotive Software IS Application GUI/RDB (Order Entry) Walker Royce 7 13 Forces in Software 7HFKQRORJ\�FKXUQ 2XU�HQHP\�LV�FRPSOH[LW\��DQG�LW¶V�RXU�JRDO�WR�NLOO�LW� -DQ�%DDQ 3HUIRUPDQFH 7KURXJKSXW &DSDFLW\ $YDLODELOLW\ )DLO�VDIH )DXOW�WROHUDQFH )XQFWLRQDOLW\ &RVW &RPSDWLELOLW\ 5HVLOLHQFH 7KH�FKDOOHQJH�RYHU�WKH�QH[W����\HDUV�ZLOO�QRW�EH�VSHHG�RU�FRVW�RU�SHUIRUPDQFH� LW�ZLOO�EH�D�TXHVWLRQ�RI�FRPSOH[LW\� %LOO�5DGXFKHO��&KLHI�6WUDWHJ\�2IILFHU��6XQ�0LFURV\VWHPV 14 The domain of architecting $UFKLWHFWXUH 4XDOLWLHV 3URFHVV $UFKLWHFWXUH� 5HSUHVHQWDWLRQ 7KH�·ZKDWµ 7KH�·ZK\µ 7KH�·KRZµ7KH�·ZKRµ 6\VWHP )HDWXUHV $UFKLWHFWXUH 6�:� 5HTXLUHPHQWV 6\VWHP 4XDOLW\�$WWULEXWHV 6DWLVILHV &RQVWUDLQ 2UJDQL]DWLRQ $UFKLWHFW 6NLOOV 6WDNHKROGHUV 'HILQHV�UROH 3URGXFHV )ROORZV 'HILQHV 7HFKQRORJ\ Wojtek Kozaczynski 8 15 We all know that ... Architecture and design are the same thing Architecture and infrastructure are the same thing is the architecture A good architecture is the work of a single architect Architecture is flat, one blueprint is enough Architecture is just structure System architecture precedes software architecture Architecture cannot be measured and validated Architecture is a Science Architecture is an Art Philippe Kruchten 16 Architecture defined (again) Architecture n (1555) 1: the art of science of building, specifically, the art or practice of designing and building structures and esp. habitable ones 2 a: formation or construction as or as if as the result of conscious act b: a unifying or coherent form or structure Merriam Webster’s Collegiate Dictionary 10th edition 9 17 Architecture defined (yet again) ‰ Software architecture encompasses the set of significant decisions about the organization of a software system - selection of the structural elements and their interfaces by which a system is composed - behavior as specified in collaborations among those elements - composition of these structural and behavioral elements into larger subsystem - architectural style that guides this organization Mary Shaw, CMU Grady Booch, Philippe Kruchten, Rich Reitman Kurt Bittner, Rational 18 Architecture defined (continued) ‰ Software architecture also involves - usage - functionality - performance - resilience - reuse - comprehensibility - economic and technology constraints and tradeoffs - aesthetic concerns Mary Shaw, CMU Grady Booch, Philippe Kruchten, Rich Reitman Kurt Bittner, Rational 10 19 Architectural style ‰ An architecture style defines a family of systems in terms of a pattern of structural organization. ‰ An architectural style defines - a vocabulary of components and connector types - a set of constraints on how they can be combined - one or more semantic models that specify how a system’s overall properties can be determined from the properties of its parts Mary Shaw, CMU 20 Architecture metamodel Software Architecture Software Architecture Description Architectural view is made of is represented by Architecture Design Process produces Form Component Connection Architectural Pattern is a is made of Software Architects are actors in Logical view Process view Implemen- tation view Deployment view Requirements satisfies Architectural style has has has is a System architecture is part of Architecture Style guide Constraints constrains constrains Use case view relates to Architectural Blueprint depicts 11 21 Models ‰ Models are the language of designer, in many disciplines ‰ Models are representations of the system to-be-built or as-built ‰ Models are vehicle for communications with various stakeholders ‰ Visual models, blueprints ‰ Scale ‰ Models allow reasoning about some characteristic of the real system 22 Many stakeholders, many views ‰ Architecture is many things to many different interested parties - end-user - customer - project manager - system engineer - developer - architect - maintainer - other developers ‰ Multidimensional reality ‰ Multiple stakeholders multiple views, multiple blueprints 12 23 Architectural view ‰ An architectural view is a simplified description (an abstraction) of a system from a particular perspective or vantage point, covering particular concerns, and omitting entities that are not relevant to this perspective 24 Architecturally significant elements ‰ Not all design is architecture ‰ Main “business” classes ‰ Important mechanisms ‰ Processors and processes ‰ Layers and subsystems ‰ Architectural views = slices through models 13 25 Characteristics of a Good Architecture ‰ Resilient ‰ Simple ‰ Approachable ‰ Clear separation of concerns ‰ Balanced distribution of responsibilities ‰ Balances economic and technology constraints 26 Representing System Architecture /RJLFDO�9LHZ (QG�XVHU� )XQFWLRQDOLW\ ,PSOHPHQWDWLRQ�9LHZ 3URJUDPPHUV� 6RIWZDUH�PDQDJHPHQW� 3URFHVV�9LHZ 3HUIRUPDQFH 6FDODELOLW\ 7KURXJKSXW� 6\VWHP�LQWHJUDWRUV ’HSOR\PHQW�9LHZ 6\VWHP�WRSRORJ\ 'HOLYHU\��LQVWDOODWLRQ &RPPXQLFDWLRQ 6\VWHP�HQJLQHHULQJ &RQFHSWXDO 3K\VLFDO 8VH�&DVH�9LHZ 14 27 Relation Between Views α β Logical view Component view Process view Deployment view 28 How many views? ‰ Simplified models to fit the context ‰ Not all systems require all views: - Single processor: drop deployment view - Single process: drop process view - Very Small program: drop implementation view ‰ Adding views: - Data view, security view 15 29 The Value of the UML ‰ Is an open standard ‰ Supports the entire software development lifecycle ‰ Supports diverse applications areas ‰ Is based on experience and needs of the user community ‰ Supported by many tools 30 Creating the UML %RRFK�PHWKRG 207 8QLILHG�0HWKRG����2236/$��� 226(2WKHU�PHWKRGV 80/����:HE���-XQH���� SXEOLF IHHGEDFN )LQDO�VXEPLVVLRQ�WR�20*��6HS�¶�� )LUVW�VXEPLVVLRQ�WR�20*��-DQ��� 80/���� 20*�$FFHSWDQFH��1RY����� 80/���� 80/���� 80/�SDUWQHUV 16 31 UML Partners ‰ Rational Software Corporation ‰ Hewlett-Packard ‰ I-Logix ‰ IBM ‰ ICON Computing ‰ Intellicorp ‰ MCI Systemhouse ‰ Microsoft ‰ ObjecTime ‰ Oracle ‰ Platinum Technology ‰ Taskon ‰ Texas Instruments/Sterling Software ‰ Unisys 32 0H\HU %HIRUH�DQG�DIWHU� �����FRQGLWLRQV +DUHO 6WDWHFKDUWV *DPPD��HW�DO )UDPHZRUNV�DQG�SDWWHUQV� +3�)XVLRQ 2SHUDWLRQ�GHVFULSWLRQV�DQG� PHVVDJH�QXPEHULQJ (PEOH\ 6LQJOHWRQ�FODVVHV�DQG KLJK�OHYHO�YLHZ :LUIV�%URFN 5HVSRQVLELOLWLHV 2GHOO &ODVVLILFDWLRQ 6KODHU���0HOORU 2EMHFW�OLIHF\FOHV 5XPEDXJK 207 %RRFK %RRFK�PHWKRG -DFREVRQ 226( Contributions to the UML 17 33 Overview of the UML ‰ The UML is a language for - visualizing - specifying - constructing - documenting the artifacts of a software-intensive system 34 Overview of the UML ‰ Modeling elements ‰ Relationships ‰ Extensibility Mechanisms ‰ Diagrams 18 35 Modeling Elements ‰ Structural elements - class, interface, collaboration, use case, active class, component, node ‰ Behavioral elements - interaction, state machine ‰ Grouping elements - package, subsystem ‰ Other elements - note 36 Relationships ‰ Dependency ‰ Association ‰ Generalization ‰ Realization 19 37 Extensibility Mechanisms ‰ Stereotype ‰ Tagged value ‰ Constraint 38 Models, Views, and Diagrams 8VH�&DVH 'LDJUDPV 8VH�&DVH 'LDJUDPV 8VH�&DVH 'LDJUDPV 6FHQDULR 'LDJUDPV 6FHQDULR 'LDJUDPV &ROODERUDWLRQ 'LDJUDPV 6WDWH 'LDJUDPV 6WDWH 'LDJUDPV &RPSRQHQW 'LDJUDPV &RPSRQHQW 'LDJUDPV &RPSRQHQW 'LDJUDPV 'HSOR\PHQW 'LDJUDPV 6WDWH 'LDJUDPV 6WDWH 'LDJUDPV 2EMHFW 'LDJUDPV 6FHQDULR 'LDJUDPV 6FHQDULR 'LDJUDPV 6WDWHFKDUW 'LDJUDPV 8VH�&DVH 'LDJUDPV 8VH�&DVH 'LDJUDPV 6HTXHQFH 'LDJUDPV 6WDWH 'LDJUDPV 6WDWH 'LDJUDPV &ODVV 'LDJUDPV $FWLYLW\ 'LDJUDPV $�PRGHO�LV�D�FRPSOHWH GHVFULSWLRQ�RI�D�V\VWHP IURP�D�SDUWLFXODU SHUVSHFWLYH 0RGHOV 20 39 Diagrams ‰ A diagram is a view into a model - Presented from the aspect of a particular stakeholder - Provides a partial representation of the system - Is semantically consistent with other views ‰ In the UML, there are nine standard diagrams - Static views: use case, class, object, component, deployment - Dynamic views: sequence, collaboration, statechart, activity 40 Use Case Diagram ‰ Captures system functionality as seen by users 21 41 Use Case Diagram ‰ Captures system functionality as seen by users ‰ Built in early stages of development ‰ Purpose - Specify the context of a system - Capture the requirements of a system - Validate a system’s architecture - Drive implementation and generate test cases ‰ Developed by analysts and domain experts 42 Class Diagram ‰ Captures the vocabulary of a system 22 43 Class Diagram ‰ Captures the vocabulary of a system ‰ Built and refined throughout development ‰ Purpose - Name and model concepts in the system - Specify collaborations - Specify logical database schemas ‰ Developed by analysts, designers, and implementers 44 Object Diagram ‰ Captures instances and links 23 45 Object Diagram ‰ Shows instances and links ‰ Built during analysis and design ‰ Purpose - Illustrate data/object structures - Specify snapshots ‰ Developed by analysts, designers, and implementers 46 Component Diagram ‰ Captures the physical structure of the implementation 24 47 Component Diagram ‰ Captures the physical structure of the implementation ‰ Built as part of architectural specification ‰ Purpose - Organize source code - Construct an executable release - Specify a physical database ‰ Developed by architects and programmers 48 Deployment Diagram ‰ Captures the topology of a system’s hardware 25 49 Deployment Diagram ‰ Captures the topology of a system’s hardware ‰ Built as part of architectural specification ‰ Purpose - Specify the distribution of components - Identify performance bottlenecks ‰ Developed by architects, networking engineers, and system engineers 50 Sequence Diagram ‰ Captures dynamic behavior (time-oriented) 26 51 Sequence Diagram ‰ Captures dynamic behavior (time-oriented) ‰ Purpose - Model flow of control - Illustrate typical scenarios 52 Collaboration Diagram ‰ Captures dynamic behavior (message- oriented) 27 53 Collaboration Diagram ‰ Captures dynamic behavior (message- oriented) ‰ Purpose - Model flow of control - Illustrate coordination of object structure and control 54 Statechart Diagram ‰ Captures dynamic behavior (event- oriented) 28 55 Statechart Diagram ‰ Captures dynamic behavior (event- oriented) ‰ Purpose - Model object lifecycle - Model reactive objects (user interfaces, devices, etc.) 56 Activity Diagram ‰ Captures dynamic behavior (activity-oriented) 29 57 Activity Diagram ‰ Captures dynamic behavior (activity-oriented) ‰ Purpose - Model business workflows - Model operations 58 Architecture and the UML 2UJDQL]DWLRQ 3DFNDJH��VXEV\VWHP ’\QDPLFV ,QWHUDFWLRQ 6WDWH�PDFKLQH ’HVLJQ�9LHZ ,PSOHPHQWDWLRQ�9LHZ 3URFHVV�9LHZ &RPSRQHQWV� &ODVVHV��LQWHUIDFHV� FROODERUDWLRQV $FWLYH�FODVVHV ’HSOR\PHQW�9LHZ 1RGHV 8VH�&DVH�9LHZ 8VH�FDVHV 30 59 Software engineering process A set of partially ordered steps intended to reach a goal. In software engineering the goal is to build a software product or to enhance an existing one. ‰ Architectural process - Sequence of activities that lead to the production of architectural artifacts: … A software architecture description … An architectural prototype 60 Rational Unified Process ‰ Iterative ‰ Architecture-centric ‰ Use-case driven ‰ Risk confronting 31 61 Focus over time Discovery Invention Focus Implementation 62 Key concepts ‰ Phase, Iterations ‰ Process Workflows - Activity, steps ‰ Artifacts - models - reports, documents ‰ Worker: Architect What does happen? What is produced? Who does it? When does architecture happen? 32 63 Lifecycle Phases WLPH ,QFHSWLRQ (ODERUDWLRQ &RQVWUXFWLRQ 7UDQVLWLRQ ‰ Inception Define the scope of the project and develop business case ‰ Elaboration Plan project, specify features, and baseline the architecture ‰ Construction Build the product ‰ Transition Transition the product to its users 64 Major Milestones WLPH 9LVLRQ� %DVHOLQH� $UFKLWHFWXUH� ,QLWLDO &DSDELOLW\� 3URGXFW� 5HOHDVH ,QFHSWLRQ (ODERUDWLRQ &RQVWUXFWLRQ 7UDQVLWLRQ 33 65 Phases and Iterations $Q�LWHUDWLRQ�LV�D�VHTXHQFH�RI�DFWLYLWLHV�ZLWK�DQ�HVWDEOLVKHG�SODQ�DQG HYDOXDWLRQ�FULWHULD��UHVXOWLQJ�LQ�DQ�H[HFXWDEOH�UHOHDVH $UFK ,WHUDWLRQ ��� 'HY� ,WHUDWLRQ 'HY� ,WHUDWLRQ ��� 7UDQV ,WHUDWLRQ ��� 5HOHDVH 5HOHDVH 5HOHDVH 5HOHDVH 5HOHDVH 5HOHDVH 5HOHDVH 5HOHDVH 3UHOLP ,WHUDWLRQ ��� ,QFHSWLRQ (ODERUDWLRQ &RQVWUXFWLRQ 7UDQVLWLRQ 66 Architecture-Centric ‰ Models are vehicles for visualizing, specifying, constructing, and documenting architecture ‰ The Unified Process prescribes the successive refinement of an executable architecture WLPH $UFKLWHFWXUH ,QFHSWLRQ (ODERUDWLRQ &RQVWUXFWLRQ 7UDQVLWLRQ 34 67 Unified Process structure Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Phases Process Workflows Iterations Supporting Workflows Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements Elaboration TransitionInception Construction 68 Architecture and Iterations 8VH�FDVH 0RGHO ’HVLJQ 0RGHO ’HSOR\PHQW 0RGHO 7HVW 0RGHO ,PSOHPHQWDWLRQ 0RGHO &RQWHQW 35 69 Architectural design ‰ Identify, select, and validate “architecturally significant” elements ‰ Not everything is architecture - Main “business” classes - Important mechanisms - Processors and processes - Layers and subsystems - Interfaces ‰ Produce a Software Architecture Documen 70 Architectural design workflow ‰ Select scenarios: criticality and risk ‰ Identify main classes and their responsibility ‰ Distribute behavior on classes ‰ Structure in subsystems, layers, define interfaces ‰ Define distribution and concurrency ‰ Implement architectural prototype ‰ Derive tests from use cases ‰ Evaluate architecture Iterate Use case view Logical view Deployment view Implementation view Process view 36 71 Sources of architecture Theft Method Intuition Classical system Unprecedented system Theft Method Intuition 72 Patterns ‰ A pattern is a solution to a problem in a context ‰ A pattern codifies specific knowledge collected from experience in a domain ‰ All well-structured systems are full of patterns - Idioms - Design patterns - Architectural patterns 37 73 Mechanisms Ø Screws • Brakes Ø Keys • Pipes Ø Rivets • Valves Ø Bearings • Springs Ø Pins, axles, shafts • Cranks and rods Ø Couplings • Cams Ø Ropes, belts, and chains • Pulleys Ø Friction wheels • Engaging gears Ø Toothed wheels Ø Flywheels Ø Levers and connecting rods Ø Click wheels and gears Ø Ratchets daVinci 74 Design patterns ‰ Creational patterns - Abstract factory - Prototype ‰ Structural patterns - Adapter - Bridge - Proxy ‰ Behavioral patterns - Chain of responsibility - Mediator - Visitor ‰ Mechanisms are the soul of an architecture Design Patterns Gamma et al 38 75 Modeling a design pattern 76 Modeling a design pattern (cont.) 39 77 Modeling a design pattern (cont.) 78 Architectural patterns Ø Distributed • Layered Ø Event-driven • MVC Ø Frame-based • IR-centric Ø Batch • Subsumption Ø Pipes and filters • Disposable Ø Repository-centric Ø Blackboard Ø Interpreter Ø Rule-based Software Architecture Shaw and Garlan Buschmann et al A System of Patterns Buschman et al Booch 40 79 Complex business system Real-Life Object-oriented Systems Soren Lauesen SQL Database Middle layer GUI layer S erviceAgent purchase(customer, produc t, items) Customer name : String Address : String save() Customer name : Str ing Address : Str ing save() get Name() updateName() Customer Order Line ** Product ** O rder L ine items : Product get Name() updateName() Observer update() Order date : Date Produc t name : Str ing price : Currency getName() updateName() Sales produc t : Product 80 Logical application architecture Relational Database Graphical User Interface Relational Database Graphical User Interface Business Object Model Graphical User Interface Business Object Model Relational Database 41 81 Physical application architecture Relational Database Server(s) Client C WWW Browser Web Server HTMLCGI ASP Java Business Object Services Business Object Engine Application Business Object Services Client A Business Object Engine Thinner client, thicker server Client B Application Business Object Services Business Object Engine Business Object Server DCOM ADO/R CORBA Beans COM MTS Beans ETS 82 Complex Internet system The Second Wave Paul Dreyfus, Netscape Client Server Application Server Fulfillment System Financial System Inventory System RDBMS Server Dynamic HTML, JavaScript, Java plug-ins, source code enhancements Java, C, C++, JavaScript, CGI Java