510 likes | 830 Views
Object-Oriented Technology and Software Reuse. Dr. Nam-Yong Lee nylee@computig.soongsil.ac.kr. 1-1, Sangdo-dong, Dongjak-gu, Seoul, Korea Phone:(02)820-0671 Handphone:011-362-5656. Information Technologies. DISTRIBUTION. National Information Super Highway. TELECOM. Info Vendors.
E N D
Object-Oriented TechnologyandSoftware Reuse Dr. Nam-Yong Lee nylee@computig.soongsil.ac.kr 1-1, Sangdo-dong, Dongjak-gu, Seoul, Korea Phone:(02)820-0671 Handphone:011-362-5656
Information Technologies DISTRIBUTION National Information Super Highway TELECOM Info Vendors E.mail, FAX,LAN, WAN Phone, Cellular, E-Conference 2-Way TV MEDIA & GUI & OS/ COMPUTER PUBLISHING PC, Engineering Workstations Super-mini, Mainframe Interactive News,, Newspapers, Newsletters Magazines & Journals Books CONSUMER ELECTRONICS Videogame, CD & Videodisc Film, TV, Video, Records & Cassettes Office Equipment Copier, Printers Scanners Medium--Transport--Translate--Transform--Present--Message/Content
What Makes Systems Complex? • Performance constraints • Time-to-market pressures • Certification requirements • Distributed, real-time requirements • Size & geographic distribution of the engineering team • Reliability and fault-tolerance requirements • Rate of requirements and technology change • The interplay of these factors Complex software costs Software cost • Diseconomy of scale Software Costs = E * (Size)P size/scale
Current Software Technology Thrusts Software Costs = E * (Size)P
Software Maintenance Cost • Total Life Cycle Cost • Development cost: 30 % • Design Cost: 40% • Code: 20 % • Integration/Testing: 40 % • Maintenance Cost: 70 % • How to reduce Maintenance Cost ? • Development Cost: 100 % • Design Cost: 40 % • Integration/Testing: 40 % • Code: 20 % • Maintenance Cost: 300 %
Establishing a Project’s Focus • Every successful project must have a set of primary characteristics against which business decisions can be made Time-to-market Scaleability Completeness Exensibility Performance Portability Quality Architectural reusability Fault tolerance • All of a project’s characteristics cannot be optimized at once • We can never have a completely rational development process
Every Software Project Has a Particular Focus • Calendar-driven • Requirements-driven • Documentation-driven • Quality-driven • Architecture-driven
Requirements-Driven Systems System function Common Infrastructure
Architecture-Driven Systems System function Domain-specific framework GUI/decktop environment Domain model Common Infrastructure Application environment Domain-independant framework Distributed object management Networking Persistent object store Basic operating system
Mitigating Software Failure • Success factors include • Languages Ada95, C++, etc. • Tools development environments, frameworks, application generators • Methods Booch, OMT, OOSE, UML • Processes SEI CMM, ISO 9000, Rational Unified Process • No one factor is sufficient • It’s an issue of balance
Object-Oriented Language Object-Based Language Procedural Language Programming Languages Lisp ALGOL60 1960 Simula 67 1970 Smalltalk-72 Smalltalk-74 Pascal Smalltalk-76 Flavors Smalltalk-78 C LOOPs Smalltalk-80 Cluster 1980 Common Lisp Ada83 C with Classes Objective C Common Loops New Flavors C++ 1.XX Eiffel CLOS C++ 2.XX 1990 C++ 3.XX Ada 95 C++ 4.XX
Tools • Development environments • Apex • Frameworks • Ship System 2000 • Taligent • UNAS • fin++ • Application Generators • Powerbuilder • Visual Basic, etc.
Methods Process maturity -- SEI CMM -- ISO 9000 Booch OMT Metrics and QA Objectory Unified Modeling Language Patterns Other methods -- CRC cards -- Responsibilty-driven design -- OBA -- Harel Formalism
Evolution of the UML Industrialization Standardization Unification Fragmentation Submission to OMGfor adoption, July ´97 UML 1.1 UML 1.0 Publication of1.0 Standard Dec ´96 UML 0.9 & 0.91 June ´96 & Oct ´96 public feedback UML PartnersExpertise Unified Method 0.8 OOPSLA ´95 Booch ´93 OMT - 2 Other methods Booch ´91 OMT - 1 OOSE
Processes • Be deliberate when considering process maturity • Successful projects will tend to rate high on the SEI CMM • A high rating on the SEI CMM does not infer success • ISO 9000 emphasizes quality and predictability • MIL-STD-498 emphasizes quality and reusability • ISO 12207 emphasizes processes • Consider acquisition processes as well • Defense Science Board: Acquiring Defense Software Commercially
Levels of Process Maturity Optimized Performance - Cost - Schedule - Quality Managed Successful Projects Defined Applicable Initial ?A successful organization will rate high in the CMM ?A high rating is not necessarily a strong predictor of success . . . . . . . .. . . . .
The Artifacts of a Software Project • Architecture • Design • Code • Requirements • Data • Human interface • Estimates • Project plans • Test plans • Documentation
Architectural Modeling Logical View Development View Scenarios Process View Platform View
Other Issues • Managing risk • Planning and scheduling • Costing and staffing • Monitoring, measuring, and testing • Documenting • Projects in crisis • Domain-specific considerations
The Development Team Documentation Analysis Tech Support Q & A Integration Application Engineers End Users Project Manager Librarian Analyst Architect Toolsmith Product Manager Patron System Administrator
General Object-Oriented Technology Trends • The language wars are over • C++ • Smalltalk • Ada95 and others • The method wars are over • Unified Modeling Language • There are a number of signs of growing maturity and acceptance • Success in a variety of application domains
The Emergence of Patterns • A pattern is a solution to a problem in a context • A pattern also expresses its author’s intent • A pattern codifies specific knowledge collected from experience in a domain • Patterns capture common design solutions • All well-structured systems are full of patterns • Idioms • Mechanisms • Frameworks • Domain-specific patterns are emerging; patterns are being collected, cataloged, and used to build systems
Distributed Computing • Most interesting applications are rarely single programs running on isolated computers • Crafting distributed, concurrent systems is very hard • Issues include • Distribution • Migration • Synchronization
Programming without Programming • Componentware • OLE and COM • OpenDoc • CORBA • Visual programming • Visual Basic • Visual C++ • JAVA(JDK) • Powerbuilder, SQL/Windows, and ObjectPro • The emergence of domain-specific frameworks
Language Comparisons • Function points are essentially language independent • SLOC are definitely language dependent • Language expressiveness as a function of: • Unadjusted Function Points===> SLOC translation ratios Language SLOC/UFP Assembly 320 Source: Capers Jones C 128 Fortran 77 105 COBOL 85 91 Ada 71 C++ 29 Ada95 ??
Megaprogramming Software TechnologyLanguage LevelSupport Software Micro programming Bits: 100, 010 Machine languages F12, A07, 124, AAF Low level programming Instructions: LDR, ADDX, Assemblers, linkers CLA, JMPS High level language Lines: IF A then B Compilers programming loop Operating systems I=I+1 Object based and Object- Objects & packages: Compilers oriented programming Type color is (red, yellow, green); Operating systems package traffic_light Runtime libraries when green go; Megaprogramming Components & Services Compilers Operating systems - Reuse Overlay map with grid; Runtime libraries - Automatic coding When failure switchover; Networks - COTS components Shutdown all test processes; Middleware CASE tools
Hardware Engineering Analogs to Megaprogramming Mega- programming Cobol C Ada83 Ada95 C++ Smalltalk System Systems Layers Rack Categories, Subsystems, Class Libraries Card Classes, Objects, LSI chip Functions, Arguments, Return values, Strong typing SSI/ MSI chip Variables, Expressions, Statements Gate
Technology State-of-the-Art Evolution Environment/Tools Target Conventional Software Engineering Separate but off-the-shelf Off-the-Shelf and integrated Custom - ad hoc 70% Megaprogrammed 30% Custom Size 100% Custom 30% Megaprogrammed 70% Custom Process/Team Ad hoc Repeatable Managed & measured Unpredictable Predictable Competitive budget & schedule performance Predictable Project Performance over budget over schedule on budget on schedule Always Infrequently
Era Design methods Process Architecture Languages Risk focus 80s 90s Declarative 2167 Proprietary distributed C-Ada Performance Software Cost Evolution Conventional Diseconomy of Scale Software Engineering Modern Best Practices Economy of scale Project Cost Software ROI Functionality, scale and complexity 60s 70s Functional Waterfall Proprietary centralized FORTRAN-COBOL Functionality 90s Object-Oriented Iterative development Open distributed Ada 95, C++ Adaptability
General Observations • Software development is hard • And demands keep increasing • You need all the help you can get • Methods • Patterns • Languages • Tools • Shared experiences • Object-oriented technology is here to stay
Object-Oriented Technology Risk Evolution • Experience: 1986 vs 1994 Early risk focus Today’s risk focus Compiler maturity/performance Personnel training Environment/tool existence Process definition Development cost Integration complexity Requirements freeze Hardware resource adequacy Personnel skill Extent of automation Process improvement Reuse cost Formal test complexity Architecture adaptability TIMES HAVE CHANGED - OOT IS VERY MATURE
Software Production SOFTWARE PRODUCTION FACTORS HUMAN TOOLS PARTS OR COMPONENTS PROCESS SOFTWARE PRODUCTS IMPROVE SOFTWARE PRODUCTIVITY GET THE BEST FROM HUMAN REUSE COMPONENTS MAKE STEPS MORE EFFICIENT ELIMINATE STEPS BUILD SIMPLER PRODUCTS ELIMINATE REWORK SOFTWARE PRODUCTIVITY IMPROVEMENT FACTORS
Software Components SYSTEM SEGMENT SEGMENT CSCI IRS HWCI HWCI CSCI IRS HWCI HWCI HWCI HWCI CSCI IRS HWCI CSC CSC CSC CSC CSC CSC CSU CSU CSC CSC CSU CSU CSU CSU CSU CSC CSC CSC CSC CSU CSU CSU CSC CSC CSU CSU CSU CSU CSU 기개발된 소프트웨어 동일한 CSU가 서로다른 CSCs에서 사용됨
Empirical Studies on Software Reuse • LEGEND • REU: Reusability • PRO: Productivity • MAI: Maintenability • GROSSORY • AXE: AXE developed by Erisson Telecom in Sweden(Oskarsson, 1983) • HAR: Hartford(Cavaliere, 1983) • TOS: Toshiba’s Software Factory(Matsumoto, 1984) • RAY: Raytheon’s Missile Systems Division(Lanergan & Grasso, 1984) • UOC: University of California at Irvine(Standish, 1984) • JAP: Japanese Software Factory(Standish, 1984) • GTE: GTE Data Services(McClure, 1992) • NAS: NASA(Selby, 1987)
Three Rs • Reusability • is an approach to software development that is based on creating software systems from reusable components that are stored in automated libraries. • Re-engineering • is the counterpart technology to CASE and the application of the newest technologies and tools to software maintenance. • Repository • is more than a CASE repository because it integrates CASE tools, re-engineering tools, third-generation, fourth-generation, and fifth-generation tools.
Reusability • Reusability is a much broader concept than simple reusable code. • Possibilities of reusable components include: • Abstract • Higher-level software components such as design, models, data, and project management information • Higher levels of reusability offers greater promise because they have greater potential to increase software productivity. • Repository provides the library mechanism and representation formalism needed for reusability. • The repository and re-engineering tools are the enabling tools for reusability.
Re-engineering • Re-engineering Technologies: • Program code analyzers and metrics • Program logic restructuring • Data restructuring • Reverse engineering • Configuration and change management • Re-engineering tools: • Program analyzers • Metrics tools • Restructuring tools • Reverse engineering tools • Translators and converters
Reverse Engineering • Reverse engineering is the process of deriving a conceptual or logical description of a software system’s contents and components from its physical level description with the aid of automated tools REVERSE ENGINEERING PROCESS Spec. Language Data Models Process Models Interrelationships JCL Source code DDL File Description Reverse Engineer LOGICAL LEVEL (DESIGN-ORIENTED) PHYSICAL LEVEL (IMPLEMENTATION-ORIENTED)
Process Reuse Framework Goals, Strategies, Tailed Processes, Resources PLAN CREATE Assets Assets and Descriptions Needs, Lessons learned, Process Assets Lessons MANAGE Lessons Needs UTILIZE
Reuse Process • Adaptive Process to Support Reuse • Parameterized Process to Support Reuse • Engineered Process to Support Reuse
Adaptive Process to Support Reuse Domain Artifact EXISTING SOFTWARE Reused Software ADAPTIVE ENGINEERING New Artifact MODIFIED SYSTEM Ported Software NEW PLATFORM
Parameterized Process to Support Reuse EXISTING SOFTWARE PARAMETERIZED SOFTWARE MODIFIED SYSTEM DOMAIN ARTIFACT PARAMETERIZED ENGINEERING REUSED SOFTWARE NEW APPLICATION NEW ARTIFACT DOMAIN RESOURCES FEEDBACK STANDARD PRODUCTS
Engineered Process to Support Reuse EXISTING SOFTWARE Domain Resources DOMIAIN ENGINEERING Domain and Software Architectures NEW APPLICATION Feedback Dmain Artifact REUSE ENGINEERING DOMAIN ANALYSIS DOMAIN DATA Reuse-Engineered Software Technology base Domain Expertise Theory Domain Knowledge Reuse-Based Software Practices
Domain Analysis Techniques • FODA(Feature-Oriented Domain Analysis) • Jaworski Technique • Prieto-Diaz technique • Synthesis Technique
Concept Development Data Items Mission Need Statement Automation Economic Analysis System Decision Paper Project Manager Charter Acquisition Strategy and Plan Statement Of Work Work Breakdown Structure Independent Cost Estimation Product Management Plan Development and Implementation Plan Operational Concept Document Data Requirement Document System Segment Specification Management Data Items System Engineering Management Plan Data Communication Network Master Plan Software Development Plan Software Configuration Management Plan Software Standards and Procedures Manual Software Quality Evaluation Plan Integration Test Plan System Security Plan Engineering Data Items System/Segment Specification Software Requirement Specification Interface Requirement Specification Software Top Level Design Document Selected and Reusable Data Items
Engineering Data Items System Allocation Document Software Detailed Design Document Interface Design Document Data-Base Design Document Software Product Specification Version Description Document Engineering Change Proposal Specification Change Notice Interface Control Document Others: System/Design Trade-Off Study Report System/Equipment Failure & Repair Study Report Program Review Documents Safety Evaluation Report Test Data Items Hardware Test Plan Software Test Plan Software Test Description Software Test Procedures Software Test Reports System Integration Test Plan Vendor Acceptance Test Plan Software Quality Test Plan Software Acceptance Test Plan System Acceptance Test Plan Others Selected and Reusable Data Items
Selected and Reusable Data Items • Operational & Support Data Items • Computer Systems Operator’s Manual • Software User’s Manual • Computer System Diagnostic Manual • Software Programmer’s Manual • Firmware Support Manual • Computer Resources Integrated Support Document • Others
Customer Applications Future Applications Windchill Product Families Windchill Enterprise Configuration Manager Change Control View Management Product Structure Management Windchill Information Modeler Workflow Management Windchill Enterprise Document Manager Life Cycle Management Document Management Federation Administrator Windchill Foundation
Information Infrastructure Cross Functional / Cross Service Integration ENTERPRISE INTEGRATION Functional Applications Base/ Tactical Applications Mission Support Applications C2 Applications Intelligence Applications Future Applications Tactical Integration Shared Services, Technologies & Data Shared Data Futute Services DMS EC/EDI DII COE Base/ Tactical Infrastructure DII Control Concept Technical Infrastructure Mega centers Future Infrastructure DISN Information Warfare/ Information Security Modeling/ System Simulation Test and Evaluation Technology Base Software Engineering Standards Architecture DII Policy Foundation