Object Technology and RUP Software Economics Why Objects? RUP - Architecture Viewpoint Large System Development Using Subsystems Software Economics: The Motivation for Object Technologies and Iterative Development - Craig Laiman Software A Risky Business Business as usual is not working. Not Compl eted 30% Source: Standish Report, 1994 Compl eted 70% All based on waterfall lifecycle. 53% cost almost 200% of original estimate. Estimated $81 billion spent on failed U.S. projects in 1995. Faulty Assumption 1: Requirements can be Fairly Accurate Applied Software Measurement, Capers Jones, 1997. Based on 6,700 systems. Creeping Req's as % of Orig 60 50 40 30 20 10 0 10 100 1000 10000 100000 Project Size in Function Points Faulty Assumption 2: Requirements are Stable The market changes constantly. Faulty Assumption 3: The Design can be Done, before Programming Ask a programmer. Requirements are incomplete and changing. The technology changes. The goals of the stakeholders change. Too many variables, unknowns, and novelties. A complete specification must be as detailed as code itself. Software is very hard. Discover Magazine, 1999: Software characterized as the most complex machine humankind builds. 1
Person Months Effort The Danger of Large Steps 80000 70000 60000 50000 40000 30000 20000 10000 0 1 20 267 4362 66690 10 100 1000 10000 100000 Project Size in Function Points Sobrce: Appliebd Software Measurement, Capers Jones, 1997. Based on 6,700 systems. SLOC/Person Month Productivity The Danger of Large Steps 4500 4000 3500 3000 2500 2000 1500 1000 500 0 1 10 100 1000 Project Size in KSLOC Source: Measures For Excellence, Putnam, 1992. Based on 1,600 systems. The Voice of Experience and Research In 1994, the DOD dropped their waterfall 2167A specification, because of abysmal failure. They now encourage an iterative process. Virtual every publication on software development process written in the last 5 years has advocated replacing a waterfall with an iterative lifecycle. The Unified Software Development Process Applying UML and Patterns Software Project Management Succeeding with Objects Object Solutions Surviving Object-oriented Projects. Therefore... Iterative Development Small steps, feedback and refinement. Iterative, incremental, time-boxed. AKA evolutionary, spiral,... A Popular Iterative Process The Rational Unified Process Iteration 1 Iteration 2... Analyze Design Code, Test, Integrate Analyze Design Code, Test, Integrate 2 weeks 2 weeks 2
Other Code Test Design The Cost of Change Strategic rational system development plans are based on the complete cost of a system, not solely on development costs. Randomly selected U.S. government software projects: Used but extensively reworked or later abandoned 19% The Cost of Change Used after changes 3% Used as delivered 2% Delivered but never successfully used 47% Doc Source: DP Budget, Vol. 7, No. 12, Dec. 1988 Revise & Maintain Paid for but not delivered 29% Source: US Government Accounting Office. Report FGMSD-80-4. The Cost of Change An AT&T study indicated that, on average, Why Object Technology? Prime software problems are Lowering the cost and time of change Increasing the ease of adaptability Fact: Object technology is especially good at Reducing the time to adapt an existing system (quicker reaction to changes in the business environment). Reducing the effort, complexity, and cost of change. Why Object Technology? What about reuse? The Corporate Use of OT, Dec 1997, Cutter Group. Prioritized reasons for adopting OT: 1. Ability to take advantage of new operating systems and tools 2. Application maintenance Note high priority 3. Cost savings 4. Development of revenue-producing applications 5. Encapsulation of existing applications 6. Improved interfaces 7. Increased productivity 8. Participation in "the future of computing" 9. Proof of ability to do OO development 10. Quick development of strategic applications 11. Software reuse Note low priority What about reuse? Why Object Technology Reuse is a good and worthy goal, but you will discover that the real power and advantage of OT is its capacity to support easily adaptable systems. Unfortunately, reuse is hard, and expert OT organizations see little of it. The issues are more organizational than technical. 3
Object Reuse Versus Cohesive Framework Reuse Reuse at What Level? Research shows no relationship between increased reuse and collecting a library of reusable components from prior projects. Communications of the ACM, pp 75-87 June, 1995. http://ite.gmu.edu/~nnada/pap.html Reuse is not usually achieved or worthwhile at the objectlevel. Focus on: The organizational factors to support reuse. http://ite.gmu.edu/~nnada/pap.html Software Reuse (Griss) A culture of framework creation and use. Reuse of architecture, analysis and design patterns. Reuse at the Framework Level Where do expert OT organizations see some reuse? With frameworks. Why Object Technology? Another non-technical, but non-trivial reason is... Ability to attract and retain talented software engineers. However, effective reusable framework creation requires: Very skilled object designers/programmers. OT is the undisputed hot technology for the foreseeable future, and it is not easy to retain talent unless an IT organization is using it. Why Object Technology? Organizations usually start the adoption thinking OT will lead to shorter development time, more reuse, better productivity. Unfortunately, that does not usually happen. However, they do discover something useful and powerful... It takes complexity to manage complexity. R. Martin, Editor of C++ Report, co-author of Object- Oriented Analysis and Design, with Grady Booch. Why Object Technology? The value of OT (OOA&D, OOP) primarily lies in its ability to handle complex problems and create comprehensible, manageable systems that can scale up to increasing complexity, and that are easily adaptable if designed skillfully. Craig Larman 1. Elegantly tackle complexity & create easy adaptability. The productivity is realized in the 2.... maintenance or modification phases of 9. Productivity a system often with profoundly faster 10.Reuse changes, if the system was designed skillfully. 4
5
6
Object Modeling with OMG UML Tutorial Series Advanced Modeling with UML - Subsystems Karin Palmkvist, Bran Selic, Jos Warmer and Nathan Dykman UML Revision Task Force Subsystem What are Subsystems? Core Concepts Diagram Tour When to Use Subsystems Modeling Tips 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys Subsystem Subsystem Example Traffic Control Subsystems are used for system decomposition Communicating subsystems constitute a system Subscription 7
Subsystem Core Concepts Construct Description Syntax A grouping of model elements that represents a behavioral unit in a physical system. Name Subsystem Aspects A subsystem has two aspects: An external view, showing the services provided by the subsystem An internal view, showing the realization of the subsystem There is a mapping between the two aspects Subsystem Aspects Subsystem Realization Realization elements Realization elements? A subsystem has a specification and a realization to represent the two views The subsystem realization defines the actual contents of the subsystem The subsystem realization typically consists of classes and their relationships, or a contained hierarchy of subsystems with classes as leaves Subsystem Specification Realization elements? Subsystem Specification The subsystem specification describes the services offered by the subsystem describes the externally experienced behavior of the subsystem does not reveal the internal structure of the subsystem describes the interface of the subsystem The subsystem specification defines the external view of the subsystem 8
Specification Techniques Use Case Approach Realization elements The Use Case approach The State Machine approach The Logical Class approach The Operation approach and combinations of these. For subsystem services used in certain sequences When the specification is to be understood by nontechnical people Use Case Approach Example Realization elements State Machine Approach Stopped Running Operator Subscription Change Digit Analysis Information Initiate Call Receive Digit and Connect Hook Signal and Disconnect Error Maintenance Exhausted For subsystems with state dependent behavior Focuses on the states of the subsystem and the transitions between them Logical Class Approach Analyzer Network Manager Number Dictionary When usage of the subsystem is perceived as manipulation of objects When the requirements are guided by a particular standard Operation Approach Operations initiateconnection ( ) dialleddigit ( ) throughconnect ( ) banswer ( ) bonhook ( ) aonhook ( ) For subsystems providing simple, atomic services When the operations are invoked independently 9
Mixing Techniques Complete Subsystem Notation Operations changedigitanalysisinformation (...) Operations Realization elements Initiate Call Subscription Receive Digit and Connect Hook Signal and Disconnect The complete subsystem symbol has three pre-defined compartments Each of the compartments may be optionally omitted from the diagram Subsystem Interfaces Operations and Interfaces Traffic Control Subscription «Interface» operation1( ) operation2( ) operation4( ) «realize» Operations operation1( ) : Type1 operation2( ) : Type2 «realize» «Interface» operation2( ) operation3( ) operation5( ) operation3( ) : Type3 operation4( ) : Type4 operation5( ) : Type5 Traffic Control Subscription The subsystem must support all operations in the offered interfaces «Interface» «realize» Subsystem Interfaces «realize» «Interface» An interface operation may alternatively be supported by a specification element of the subsystem Specification Realization The specification and the realization must be consistent The mapping between the specification and the realization can be expressed by: realization relationships collaborations 10
Realize Relationship Realize Example Operations operation1( ) : Type1 operation2( ) : Type2 operation3( ) : Type3 «realize» Realization Elements operation1( ) Operations changedigitanalysisinformation ( ) Realization elements «realize» operation4( ) : Type4 operation5( ) : Type5 Initiate Call Receive Digit and Connect changedigitanalysisinformation ( ) : Realization is particularly useful in simple mappings Subscription Hook Signal and Disconnect Collaboration A collaboration defines the roles to be played when a task is performed The roles are played by interacting instances Collaboration Notation Collaboration Role role name Sequence Diagram : : :Subscription markbusy Collaboration Diagram 2: dialleddigit 3: dialleddigit 6: banswer : Class role name role name role name dialleddigit 4: throughconnect dialleddigit : throughconnect Answer markbusy 1: markbusy 5: markbusy :Subscription A collaboration and its participants Collaboration Example Subsystem Interaction Realization elements Initiate Call Network Interface Receive Digit and Connect Coordinator Analysis Database Hook Signal and Disconnect Collaborations are useful in more complex situations 1:transmit 3:ack 4:receive 2:send 1.4 11
Communicating with Subsystems Two approaches: Open subsystem - public elements are accessed directly Closed subsystem - access via the subsystem itself Open Subsystems -B +A «import» +TC::A -C +B A subsystem is called open if its realization is used directly by the environment The specification acts as an overview of the subsystem as a requirements specification 1.4 1.4 Closed Subsystems +A -B -C +B A subsystem is called closed if its realization is not directly used by the environment The specification acts as an overview of the subsystem as a requirements specification as a specification of how to use the subsystem Subsystem Instance : A subsystem instance is the runtime representation of a subsystem. Its task is to handle incoming stimuli. 1.4 1.4 Subsystem Inheritance A subsystem with a generalization to another subsystem inherits public and protected elements that are owned or imported by the inherited subsystem Both specification elements and realization elements are inherited Operations are also inherited Diagram Tour Subsystems can be shown in static diagrams and interaction diagrams Fork notation alternative for showing contents: Realization elements Realization elements 12
Diagram Tour continued Subsystems can be shown in interaction diagrams collaboration diagrams sequence diagrams Sequence Diagram When to Use Subsystems To express how a large system is decomposed into smaller parts Distributed development To express how a set of modules are composed into a large system For component based development «call» ArtStore Client «call» Component Based Development ShoppingCart Specification Elements «Interface» ShoppingCartHome create( ) findbyprimarykey( )... «Interface» ShoppingCart getitemcount( ) setitemcount( ) gettotal( ) settotal( )... Realization Elements «auxiliaryclass» HomeObject «auxiliaryclass» RemoteObject «call» «call» ShoppingCart Home ShoppingCart «focalclass» ShoppingCart Impl Context «auxiliaryclass» ContextObject An EJB component modeled using a subsystem and classes stereotyped «focalclass» or «auxiliaryclass» «auxiliaryclass» ShoppingCart DBbroker Modeling Tips Subsystem Define a subsystem for each separate part of a large system Choose specification technique depending on factors like kind of system and kind of subsystem Realize each subsystem independently, using the specification as a requirements specification 1.4 13