Beruflich Dokumente
Kultur Dokumente
Part 1 of 2
23
Balanced Attack
Can improve software economics Easy to do so and have poor results Key is a balanced approach; patient Five Key Initiatives In Order:
Reducing the size and/or complexity of application Improving the development process itself Using more-skilled personnel and creation of better teams Creating better environments with appropriate tools and technology to foster improvement Re-looking at Quality
23
2
This lecture
We will concentrate on
Reducing the Size (most slides), and a little on Looking at the Process.
23
Trends
Higher Order Languages (C++, Java, VB, OO (analysis, design, programming) Reuse Commercial Components
Integrated tools (visual modeling, compiler, editors, debuggers, CMS, . Open Systems Hardware platform performance Automation of coding, documents, testing, analyses
The larger the product, the more expensive it is per line. Fact. Complicated due to
Component-based development Automatic code generation Instruction Explosion GUI builders 4GLs Modeling Languages Executable code size often increases!
23
6
SLOC metrics:
Comparison Table
LANGUAGE
Assembler Language
C
Fortran 77 Cobol 85 Ada 83 C++
128
105 91 71 56
Ada 95
Java
55
55
23
Visual Basic
35
Use table as a general comparison guide only. Languages (in general) are often best suited for classes of problems (domain of usage)
Web-based apps: Transaction processing: Systems programming: Prototyping UI: Java vs COBOL Java vs COBOL Assembler vs C vs Java VB versus Java (varies)
Function Points focus more on functionality. The implementing programming language size can be inferred from function point count. Not simple to compute function points tho
Automatic code generators (CASE; GUI) can reduce size of human generated code less time; fewer team members(helps cost; efficiency of automatic code generators? Function point computation?) Commercial DBMSs, GUI Builders, middleware, reduce the amount of code to be developed
Others!!
23
10
Reducing size changes level of abstraction allowing us to focus on architecture, easier to understand, reuse, maintain. (may import packages of classes and objects)
We can talk about layers, dependencies, interfaces, services! Can talk about classes, subsystems, packages. These are serious abstractions!
But, these higher-level abstractions are often high users of storage, and communications bandwidth
23
11
Package Expressiveness
A package is a general purpose mechanism for organizing elements into groups (use cases; classes, other model elements) Package is a model element which can contain other model elements
Packages may contain many model elements: use case models, classes, objects, subsystems, components, other packages.
Package Name
General grouping for organizational purposes May have tremendous expressiveness Think Math class in Java
23
12
Subsystem - Expressiveness
A combination of a package
groups similar model elements and a class has behaviors via its methods. (classes provide / encapsulate behaviors or services)
Subsystem
nterface
Interface (a class)
23
Components (in the implementation model) can be used to represent the subsystems from the design model.
Design Model
<<subsystem>> Component Name
Implementation Model
Component Name
Component Interface
Component Interface
23
14
OO technology reduces size (among other things), but there is no free lunch.
23
15
Glossary; domain model; artifacts ; object concepts and terms Easy to talk about subsystems, classes, interfaces Architecture first approach for stability, planning teams, iteration plans,
Architecture provides a clear separation of concerns for development in parallel; configuration; integrity of development And then, when you consider the RUP as a process built around OO technology, there are a host of additional benefits.
23
16
Old stuff: data descriptions; documents, and a host of similar, old artifacts, designs, architectures from all phases of software development Common architectures; processes, common environments... Very common during monolithic type development.
Common Microsoft platforms: - counter example Linux; MACs, resulting from distributing applications!
23
17
C. Reuse (continued)
Main reason for Reuse or lack thereof: money. (not addressing commercial components)
Costs to build reusable and configure reusable components. Must be able to justify. Can reuse be justified across many projects? Some commercial organizations focused on selling commercial components.
Very few success stories for software component reuse Most developers do undertake some kind of reuse just perhaps not as formalized
23
18
Major trend buy commercial components. Saves custom development Usually needs tailoring Certainly pros and cons. Bottom line: may well have global impacts on:
quality cost supportability, and the architecture.
23
19
ADVANTAGES
Predictable license costs Broadly used, mature technology Available now Dedicated support organizations Hardware/software independence Rich in functionality
DISADVANTAGES
Frequent upgrades Up-front license fees Recurring maintenance fees Dependency on vendor Run-time efficiency sacrifices Functionality constraints
Custom Development
23
20
Objective: minimize overhead and direct these energies toward production activities.
23
21
First approach
We want the highest quality system with fewest iterations in least time.
more efficient steps older approach - is good, more ROI on second (fewer steps) and third (concurrency in activities)
Must eliminate rework and late scrap fixing things up! Integration testing is culprit. Fixing things up as a result of integration and system tests are killers!!!