Previous | Table of Contents | Next
Page 375
Determining the Number of CASE Applications to
UseA number of questions should be answered to determine the number of CASE applications to use. These include:
- What is the structure of the organization?
- How good is the intergroup communication?
- What is the size of the application?
- Are the designers familiar with CASE techniques?
- What is more important, control or flexibility?
Several strategies can be used, and each has its pros and cons.
Centralized ConfigurationIn a centralized
configuration, all the data is owned by one application and the others share this data.
The advantages to this strategy include:
- Ease of administration, because there is only one set of access rights to maintain.
- No element transfer is needed because all the elements are owned by one application.
- Version control is simplified.
The disadvantages to this strategy include:
- Requires all the users to access one database (single point of failure).
- Requires greater communication between groups because they all share the same
data and therefore have to agree on a lot of things.
- Results in larger systems and therefore utilities take longer to run.
Decentralized ConfigurationDecentralized
configuration means that each application owns its own data and can
grant privileges on its elements to other applications as needed.
The advantages to this strategy include:
- Greater flexibility than the centralized approach.
- Migration and version control of application systems can be done independently.
- Results in smaller applications and therefore utilities run faster.
- The number of development teams that can access the applications increases
without increasing the likelihood of locking each other.
The disadvantages to this strategy include:
- If applications are not well partitioned, it might result in a lot of sharing and
transferring of elements.
- Care must be taken to ensure no redundancy.
- Boundaries and objectives of individual applications have to be established well
in advance for this approach to be successful.
Page 376
Combined ConfigurationIn combined
configuration, a master application owns elements
that are common to more than one application and shares these with applications that need
them. There are also applications that contain application-specific data that is not shared with others.
The advantages to this strategy include:
- Takes the best of both worlds by enabling the sharing of elements as well as
individual application system development.
- Results in manageable applications.
The disadvantages to this strategy include:
- If not planned properly, it may result in complex version control and migration tasks at
a later stage.
- Requires a lot of administrative effort due to the flexibility it provides.
Determining the Number of RepositoriesThere are several things to consider when
determining the number of repositories. These include:
- The number of and relationship among the applications.
If you have more than one application and they share elements, they should all reside
in the same repository, because sharing between repositories is not supported.
An application should exist only in one instance; otherwise, it will result in a lot
of merging at a later stage.
Applications that have nothing in common should be placed in separate instances to
have better control over them.
- The expected number of users.
Certain utilities such as versioning run in a single-user mode, and if it is to be
run concurrently by different application systems, it might be worthwhile to place
the applications in separate instances.
Multiple instances should be considered if the physical limits of the hardware
are reached.
Each CASE user needs a certain amount of RAM, swap space, and so on. In some
cases, it will be beneficial to consider a client/server solution.
Using multiple instances can have its advantages and disadvantages:
- It can result in a fault-tolerant system.
- It does not require all the users to access the same database.
- Sharing between instances is not supported and may need periodic migration.
The pros and cons of using the different configurations are summarized in Table 15.5.
Page 377
Table 15.5Pros and Cons of Using Different Configurations
Factor to Consider
|
Centralized
|
Decentralized
|
Mixed
|
Time to administer access
privileges
|
low
|
low
|
medium
|
Ease of version control
|
high
|
low
|
medium
|
Support for parallel
system development
|
low
|
high
|
medium
|
Performance on frequently
versioned systems
|
low
|
high
|
medium
|
Need to use multiple
instances
|
low
|
high
|
medium
|
Interdependency of
applications
|
high
|
low
|
medium
|
The installation guide for Designer/2000 has a number of hardware and software
requirements that should be met. The following discussion provides suggestions that can improve the
performance of Designer/2000 (use them with caution because it might affect other Windows
applications also).
A client/server configuration works quite well with Designer/2000. However, a network
install is not recommended because there will be performance problems. A minimum of a
386 machine is required, and there is no notable difference between using one hardware
manufacturer or another. The minimum is 16MB of memory, although 32MB is
recommended. Optimize memory usage in your system with some of the following tips:
- For DOS and Windows 3.x-based systems, use SmartDrive to optimize
extended memory.
- Use a hard disk optimizer to remove fragmentation from the hard disk on a
periodic basis.
- Do not put your working directory on the LAN.
- Clear the Temp directory periodically.
- Exit and revoke Windows periodically to free up some allocated space.
- For DOS and Windows 3.x-based systems, create a permanent swap file instead of
a temporary swap file.
- Designer/2000 requires a 40MB swap file minimum.
- For DOS and Windows 3.x-based systems, use MemMaker to configure memory optimally.
Page 378
- Load drivers low instead of high.
- Rearranging the order of loading programs and drivers can help minimize fragmentation.
- Install conventional memory protectors such as FIX1MB.EXE, available on CompuServe.
- Disable screen savers.
- Unload unused fonts.
The network performance can affect overall system performance, and it should be
carefully monitored.
Get SQL*NET trace files or put sniffers to determine the network performance and where
the degradation is present. Use dead connection detection by setting
sqlnet.expire_time= <time_in_minutes> in the
sqlnet.ora. This will allow the listener to check after every
time period specified in the above setting to make sure that there are no dead connections.
Several things can be done to optimize Designer/2000:
- Rebuild CASE indexes.
- Rearrange the repository data to use the correct configuration for your environment.
- Determine the number of repositories used.
- Determine if the elements are properly shared between the application systems.
- Get diagnostic information to make sure that the SQL statements are used optimally.
- The repository is stored in its own tables in the database, and therefore, database
op-timization techniques such as removing fragmentation can be applied to Designer/2000.
Database optimizing is an art and has to be constantly performed on the database, due
to changing conditions in the database. Tuning
Oracle by Oracle Press is a very good book on different tips that can be used to optimize the database performance. The following tips can
be helpful:
- Use the correct optimizer mode (RULE-based is recommended for R 1.3.2, while
COST- based is recommended for R 2.0).
- Truncate
RM$HASH_ELMS.
- Reduce fragmentation by pinning objects properly and not using a large sort area size.
- Reduce disk I/O.
- Reduce contention and maintain a high hit ratio.
- Set LOG_CHECKPOINT_INTERVAL to be greater than the Redo Log size so that
checkpoint occurs only at a log switch.
Previous | Table of Contents | Next
|