Unit 3

Process Overview: Domain and Application

 Development stages, Analysis:
 Development life Cycle,  Class model,
 Devising a System concept,  State model
 Elaborating a concept,  Interaction model,
 Preparing a problem statement  Iterating the analysis

Process Overview:

1. Development stages
Software development has a sequence of well-defined stages. Each stage has a distinct purpose,
input, and output.
■ System conception. At this stage tentative requirements are defined.
■ Analysis. At this stage deep understanding of system is done. The goal ofanalysis is to specify
what needs to be done, not how it is done.
■ System design. At this stage high-level of system design is prepared. (the three modelling)
■ Class [Link] has been designed. Algorithms are also selected at this stage.
■ Implementation. Translate the design into programming code and database structures.
■ Testing. Ensure that the application is suitable for actual use and the requirements are met.
■ Training. Help users master the new application.
■ Deployment. Place the application in the field and gracefully.
■ Maintenance. Preserve the long-term viability of the application.

1.1 System Conception

The project manager prepares a business case, and sells the idea to the organization. The
project manager must understand both business needs and technological capabilities.
1.2 Analysis
Identify Objects: Find nouns in the problem description that represent real-world entities
or concepts.

1
 Identify Attributes: Determine the properties or data associated with each object.
Identify Methods: Define the actions or behaviors an object can perform.
Identify Relationships: Analyze how objects interact, using concepts like aggregation
(has-a) and inheritance (is-a).

1.3 System Design

 During system design, the developer makes strategic decisions with their consequences.
 The developer formulate an architecture and choose global strategies and policies.
 The choice of architecture is based on the requirementsas well as past experience.
 If possible, the architecture should include an executableskeleton.
 The system designer must understand how a new system interactswith other systems.
 The architecture must also support future modification of the application.

1.4 Class Design

 Developers choose algorithmsto implement major system functions
1.5 Implementation
Implementation is the stage for writing the actual code. Developers map design elements
toprogramming language and database code.
1.6 Testing
 After implementation, the system is complete, but it must be carefully tested before
actual use.
 Testers once again revisit the originalbusiness requirements and verify that the system
delivers the proper functionality.
 Tester should check a program at several levels.
o Unit Testing
o Module Testing
o Program Testing
o Software testing
o User acceptance testing
1.7 Training
 An organization must train users so that they can fully benefit from an application.
 A separate team should prepare user documentationin parallel to the development effort.
1.8 Deployment
 The system must work in the field, on various platforms and in various configurations.
 Unexpected interactions can occur when a system is deployed in a customer environment.
 Developers must tune the system under various loads.
 Some customers will require software customizations.

2
  Staff must also localizethe product to different spoken languages.
1.9 Maintenance
 Once development is complete and a system has been deployed, it must be maintained for
continued
 success.
 Bugs that remain in the original systemwill gradually appear during use and must be
fixed.

2. Development Life Cycle

A software development life cycle (SDLC) model is a conceptual framework
describing all activities in a software development project from planning to
maintenance. This process is associated with several models, each including a variety
of tasks and [Link] development is a cumbersome activity requiring
proper identification of requirements, their implementation, and software deployment.
However, the activities do not end there. After the distribution of the software, proper
maintenance has to be provided in a timely manner.
1. Waterfall Model
The Waterfall Model was first Process Model. It is also referred to as a linear-
sequential life cycle model. In this each phase must be completed fully before the
next phase can begin. This type of model is basically used for the project which is
small and there are no uncertain requirements. At the end of each phase, a review
takes place to determine if the project is on the right path or not. In this model the
testing starts only after the development is complete. In waterfall model phases do not
overlap.

3
 Classical waterfall model divides the life cycle into the following phases as shown in
figure:
Feasibility Study
In this step we determine whether it would be financially and technically possible to
develop the product or not. For this following steps are taken-
1. Characterstics of different input and output data are analyzed.
2. Type of processing needed to convert I/P data into O/P data are identified. Along
with this various constraints of the system are identified.
3. After understanding the problem,engineers investigate the different possible
solutions.
4. Then required resources, cost of development and development time for each
solution has been calculated.
5. Based on this analysis they pick the best solution and determine whether the
solution is feasible financially and technically.
Requirements Analysis and Specification
The aim of the requirements analysis and specification phase is to understand the
exact requirements of the customer and to document them properly. This phase
consists of two distinct activities, namely
1. Requirements gathering and analysis, and
2. Requirements specification
In requirements gathering activity the project team collects all relevant information
regarding the product. For this many interviews and discussions may be required. After

4
all information (ambiguities and incompleteness) have been collected, the requirements
specification activity can start. During this activity, the user requirements are
systematically organized into a Software Requirements Specification (SRS) document.
Design
In this step the requirements which are specified in the SRS document are
converted into a programming format. Two different methods can be used: the
traditionaldesign approach and the object-oriented design approach. So Output of this
phase is a logical structure of software.
Coding and unit testing
In this step the programmers convert logical structure of s/w in to source code.
Each component of the design is implemented as a program module. After this each
module is tested to check whether all modules are working properly or not. The end-
product of this phase is a set of program modules that have been individually tested.
Integration and system testing: -
During the integration and system testing phase, the modules are combined in a
planned manner. The different modules are never integrated in one shot. Integration is
normally carried out incrementally. During each integration step, the partially integrated
system is tested. Finally, when all the modules have been successfully integrated and
tested, system testing is carried out.
Maintenance
Maintenance requires more efforts than the effort necessary to develop the product
itself. Maintenance involves performing any one or more of the following three kinds of
activities:
 Correcting errors that were not discovered during the product development
phase. This is called corrective maintenance.
 Improving the implementation of the system, and enhancing the functionalities
of the system according to the customer’s requirements. This is called
perfective maintenance.
 Porting the software to work in a new environment. For example, porting may
be required to get the software to work on a new computer platform or with a
new operating system. This is calledadaptive maintenance.
Advantages of waterfall model:
 This model is simple and easy to understand and use.
 It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
 In this model phases are processed and completed one at a time. Phases do not
overlap.
5
  Waterfall model works well for smaller projects where requirements are very well
understood.
Disadvantages of waterfall model:
 Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage.
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of
changing.
When to use the waterfall model:
 This model is used only when the requirements are very well known, clear and
fixed.
 Product definition is stable.
 Technology is understood.
 There are no ambiguous requirements
 Ample resources with required expertise are available freely
 The project is short.

2. Prototyping
Prototyping is defined as the process of developing a working replication of a product
or system that has to be engineered. It offers a small scale facsimile of the end
product and is used for obtaining customer feedback as described below:

The Prototyping Model is one of the most popularly used Software Development Life
Cycle Models (SDLC models). This model is used when the customers do not know
the exact project requirements beforehand. In this model, a prototype of the end
product is first developed, tested and refined as per customer feedback repeatedly till
a final acceptable prototype is achieved which forms the basis for developing the final
product.

6
In this process model, the system is partially implemented before or during the
analysis phase thereby giving the customers an opportunity to see the product early in
the life cycle. The process starts by interviewing the customers and developing the
incomplete high-level paper model. This document is used to build the initial
prototype supporting only the basic functionality as desired by the customer. Once the
customer figures out the problems, the prototype is further refined to eliminate them.
The process continues until the user approves the prototype and finds the working
model to be satisfactory. There are four types of models available:

A) Rapid Throwaway Prototyping –

This technique offers a useful method of exploring ideas and getting customer
feedback for each of them. In this method, a developed prototype need not necessarily
be a part of the ultimately accepted prototype. Customer feedback helps in preventing
unnecessary design faults and hence, the final prototype developed is of better
quality.

B) Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally refined on the basis
of customer feedback till it finally gets accepted.
C) Incremental Prototyping – In this type of incremental Prototyping, the final
expected product is broken into different small pieces of prototypes and being
developed individually. In the end, when all individual pieces are properly developed,
then the different prototypes are collectively merged into a single final product in
their predefined order.
D) Extreme Prototyping – This method is mainly used for web development. It is
consists of three sequential independent phases:
D.1) In this phase a basic prototype with all the existing static pages are presented in
the HTML format.
D.2) In the 2nd phase, Functional screens are made with a simulated data process
using a prototype services layer.
D.3) This is the final step where all the services are implemented and associated with
the final prototype.

7
Advantages –

 The customers get to see the partial product early in the life cycle. This ensures a
greater level of customer satisfaction and comfort.
 New requirements can be easily accommodated as there is scope for refinement.
 Missing functionalities can be easily figured out.
 Errors can be detected much earlier thereby saving a lot of effort and cost, besides
enhancing the quality of the software.

8
  Flexibility in design.

Disadvantages –
 Costly w.r.t time as well as money.
 There may be too much variation in requirements each time the prototype is
evaluated by the customer.
 Poor Documentation due to continuously changing customer requirements.
 It is very difficult for developers to accommodate all the changes demanded by the
customer.
 There is uncertainty in determining the number of iterations that would be required
before the prototype is finally accepted by the customer.
 After seeing an early prototype, the customers sometimes demand the actual
product to be delivered soon.
 Developers in a hurry to build prototypes may end up with sub-optimal solutions.
 The customer might lose interest in the product if he/she is not satisfied with the
initial prototype.

Use –
The Prototyping Model should be used when the requirements of the product are not
clearly understood or are unstable. It can also be used if requirements are changing
quickly. This model can be successfully used for developing user interfaces, high
technology software-intensive systems, and systems with complex algorithms and
interfaces. It is also a very good choice to demonstrate the technical feasibility of the
product.

3. Incremental Model
The incremental process model is also known as the Successive version model.
First, a simple working system implementing only a few basic features is built and
then that is delivered to the customer. Then thereafter many successive iterations/
versions are implemented and delivered to the customer until the desired system is
released.

A, B, and C are modules of Software Products that are incrementally developed and
delivered.

9
Life cycle activities:
Requirements of Software are first broken down into several modules that can be
incrementally constructed and delivered. At any time, the plan is made just for the
next increment and not for any kind of long-term plan. Therefore, it is easier to
modify the version as per the need of the customer. The Development Team first
undertakes to develop core features of the system.
Once the core features are fully developed, then these are refined to increase levels of
capabilities by adding new functions in Successive versions. Each incremental
version is usually developed using an iterative waterfall model of development.
As each successive version of the feedback of the Customer taken and feedback is
incorporated into the next version. Each version of the software has more additional
features than the previous ones.

Types of Incremental model:

1. Staged Delivery Model: Construction of only one part of the project at a time.

10
2. Parallel Development Model – Different subsystems are developed at the same
time. It can decrease the calendar time needed for the development, i.e. TTM (Time
to Market).

11
 When to use this:
1. Funding Schedule, Risk, Program Complexity, or need for early realization of
benefits.
2. When Requirements are known up-front.
3. When Projects have lengthy development schedules.
4. Projects with new Technology.
5. Requires good planning and design.
6. The total cost is not lower.
7. Well-defined module interfaces are required.
Advantages-
1. Prepares the software fast.
2. Clients have a clear idea of the project.
3. Changes are easy to implement.
4. Provides risk handling support, because of its iterations.
Disadvantages-
1. A good team and proper planned execution are required.
2. Because of its continuous iterations the cost increases.

4. RAD
RAD Model or Rapid Application Development Model is similar to incremental
model andwaterfall model. In RAD Model, development should be done in specified
time frame. RAD Model is suitable for the small project where all the requirements
are gathered before starting development of the project. Once client gives the
feedback, based on the client’s feedback other changes are done. This process goes
parallel with co-operation with client and developers. Each prototype is delivered to
the client with working functionality and changes made based on the client’s
feedback. Development moves faster in RAD Model with minimum errors. RAD
Model follows the incremental delivery of the modules. The main goal or RAD
Model is to make the reusability of the developed components.
Phases in RAD Model:
 Business Modeling
 Data Modeling
 Process Modeling
 Application Modeling
 Testing and Turnover

12
 Business Modeling: In this phase of development business model should be designed
based on the information available from different business activities. Before start the
development there should be a complete picture of business process functionality.
Data Modeling: Once the business modeling phase over and all the business analysis
completed, all the required and necessary data based on business analysis are
identified in data modeling phase.
Process Modeling: All the data identified in data modeling phase are planned to
process or implement the identified data to achieve the business functionality flow. In
this phase all the data modification process is defined.
Application Modeling: In this phase application id developed and coding completed.
With help of automation tools all data implemented and processed to work as real
time.
Testing and turnover: All the testing activates are performed to test the developed
application.
Advantages of RAD Model:
 Fast application development and delivery.
 Lest testing activity required.
 Visualization of progress.
 Less resources required.
 Review by the client from the very beginning of development so very less chance
to miss the requirements.
 Very flexible if any changes required.
 Cost effective.
 Good for small projects.
Disadvantages of RAD Model:
 High skilled resources required.
 On each development phase client’s feedback required.
 Automated code generation is very costly.
 Difficult to manage.

13
  Not a good process for long term and big projects.
 Proper modularization of project required.
When RAD Model should be followed:
 For low budges projects for which automated code generation cost is low.
 When high skilled resources are available.
 When it’s easy to modularize the project.
 If technical risks are low.
 If development needed to complete in specified time.
 RAD Model is suitable if the functionality have less dependencies on other
functionality.

5. Spiral Model.
Spiral model is one of the most important Software Development Life Cycle models,
which provides support for Risk Handling. In its diagrammatic representation, it
looks like a spiral with many loops. The exact number of loops of the spiral is
unknown and can vary from project to project. Each loop of the spiral is called
a Phase of the software development process. The exact number of phases needed
to develop the product can be varied by the project manager depending upon the
project risks. As the project manager dynamically determines the number of phases,
so the project manager has an important role to develop a product using the spiral
model.
The Radius of the spiral at any point represents the expenses(cost) of the project so
far, and the angular dimension represents the progress made so far in the current
phase.
The below diagram shows the different phases of the Spiral Model: –

14
Each phase of the Spiral Model is divided into four quadrants as shown in the above
figure. The functions of these four quadrants are discussed below-
1. Objectives determination and identify alternative solutions: Requirements are
gathered from the customers and the objectives are identified, elaborated, and
analyzed at the start of every phase. Then alternative solutions possible for the
phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions
are evaluated to select the best possible solution. Then the risks associated with
that solution are identified and the risks are resolved using the best possible
strategy. At the end of this quadrant, the Prototype is built for the best possible
solution.
3. Develop next version of the Product: During the third quadrant, the identified
features are developed and verified through testing. At the end of the third
quadrant, the next version of the software is available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers
evaluate the so far developed version of the software. In the end, planning for the
next phase is started.
Risk Handling in Spiral Model
A risk is any adverse situation that might affect the successful completion of a
software project. The most important feature of the spiral model is handling these
unknown risks after the project has started. Such risk resolutions are easier done by
developing a prototype. The spiral model supports coping up with risks by providing
the scope to build a prototype at every phase of the software development.
15
 The Prototyping Modelalso supports risk handling, but the risks must be identified
completely before the start of the development work of the project. But in real life
project risk may occur after the development work starts, in that case, we cannot use
the Prototyping Model. In each phase of the Spiral Model, the features of the product
dated and analyzed, and the risks at that point in time are identified and are resolved
through prototyping. Thus, this model is much more flexible compared to other
SDLC models.
Why Spiral Model is called Meta Model?
The Spiral model is called a Meta-Model because it subsumes all the other SDLC
models. For example, a single loop spiral actually represents the Iterative Waterfall
Model. The spiral model incorporates the stepwise approach of the Classical
Waterfall Model. The spiral model uses the approach of the Prototyping Model by
building a prototype at the start of each phase as a risk-handling technique. Also, the
spiral model can be considered as supporting the Evolutionary model – the iterations
along the spiral can be considered as evolutionary levels through which the complete
system is built.
Advantages of Spiral Model:
Below are some advantages of the Spiral Model.
1. Risk Handling: The projects with many unknown risks that occur as the
development proceeds, in that case, Spiral Model is the best development model to
follow due to the risk analysis and risk handling at every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and
complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase
can be incorporated accurately by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the
early phase of the software development and thus, they habituated with the system
by using it before completion of the total product.
Disadvantages of Spiral Model:
Below are some main disadvantages of the spiral model.
1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the
project is very much dependent on Risk Analysis. Without very highly experienced
experts, it is going to be a failure to develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start
of the project, so time estimation is very difficult.

6. V- model
V- model means Verification and Validation model. Just like the waterfall model, the V-
Shaped life cycle is a sequential path of execution of processes. Each phase must be
16
completed before the next phase begins. Testing of the product is planned in parallel
with a corresponding phase of development in V-model.

The various phases of the V-model are as follows:

Requirements like BRS and SRS begin the life cycle model just like the waterfall model.
But, in this model before development is started, a system test plan is created. The test
plan focuses on meeting the functionality specified in the requirements gathering.
The high-level design (HLD) phase focuses on system architecture and design. It provide
overview of solution, platform, system, product and service/process. Anintegration
test plan is created in this phase as well in order to test the pieces of the software systems
ability to work together.
The low-level design (LLD) phase is where the actual software components are designed.
It defines the actual logic for each and every component of the system. Class diagram
with all the methods and relation between classes comes under LLD. Component tests are
created in this phase as well.
The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test plans
developed earlier are now put to use.
Coding: This is at the bottom of the V-Shape model. Module design is converted into
code by developers.
Advantages of V-model:

17
  Simple and easy to use.
 Testing activities like planning, test designing happens well before coding. This
saves a lot of time. Hence higher chance of success over the waterfall model.
 Proactive defect tracking – that is defects are found at early stage.
 Avoids the downward flow of the defects.
 Works well for small projects where requirements are easily understood.
Disadvantages of V-model:
 Very rigid and least flexible.
 Software is developed during the implementation phase, so no early prototypes of
the software are produced.
 If any changes happen in midway, then the test documents along with requirement
documents has to be updated.
When to use the V-model:
 The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
 The V-Shaped model should be chosen when ample technical resources are
available with needed technical expertise.
 High confidence of customer is required for choosing the V-Shaped model
approach. Since, no prototypes are produced, there is a very high risk involved in
meeting customer expectations.

3. Devising a System Concept

Most ideas for new systems are extensions of existing ideas. Here are some ways to find new system
concepts.
 New functionality. Add functionality to an existing system.
 Streamlining. Remove restrictions or generalize the way a system works.
 Simplification. Let ordinary persons perform tasks previously assigned to specialists.
 Automation. Automate manual processes.
 Integration. Combine functionality from different systems.
 Analogies. Look for analogies in other problem domains and see if they have useful
ideas.
 Globalization. Travel to other countries/ areas and observe their cultural and business
practices.

18
4. Elaborating a Concept
Most systems start as vague ideas. A good system concept mustanswer the following questions.
■ Who is the application for?
Project Manager should clearly understand which persons and organizations will use the new
system. Two of the most important kinds of stakeholdersare the financial sponsors and the end
users.
The financial sponsor are important because they are paying for the new [Link] expect the
project to be on schedule and within budget
The users are also stakeholders, but in another sense. The users will ultimately determine
the success of the new system by an increase in their productivity. They can improve your system
by telling you what is missing and what could be improved.
■ What problems will it solve?
You must face various kinds of users in organizations with their ownviewpoints and political
motivations. You must not only decide which features are appropriate,but you must also obtain the
agreement of influential persons.
■ Where will it be used?
It is important to know if the softwarewill be used locally or will be distributed via a network. For a
commercial product,you should characterize the customer base.
When is it needed?
Two aspects of time are important. The first is the feasible time, thetime in which the system can be
developed. The other is the required time, when the system is needed to meet businessgoals.

■ Why is it needed?
You may need to prepare a business case for the new system if someonehas not already done so.
The business case contains the financial justification forthe new system, including the cost, tangible
benefits, intangible benefits, risk, and [Link] must be sure that you clearly understand the
motivation for the new system.

19
5. The ATM Case Study

Figure lists our original system concept for an Automated Teller Machine (ATM). Weask high-level
questions to elaborate the initial concept.
■ Who is the application for? A number of companies provide ATM products. Consequently,only a
vendor or a large financial company could possibly justify the cost andeffort of building ATM
software.A vendor would be competing for customers in an established market. A large vendorcould
certainly enter such a market, but might find it advantageous to partner withor acquire an existing
supplier. A small vendor would need some special feature to differentiateitself from the crowd and
attract attention.
It is unlikely that a financial company could justify developing ATM software justfor its own use,
because it would probably be more expensive than purchasing a [Link] a financial company
wanted special features, it could partner with a vendor. Or itmight decide to create a separate
organization that would build the software, sell it tothe sponsoring company, and then market it to
others.
■ What problems will it solve? The ATM software is intended to serve both the bank andthe
customer. For the bank, ATM software increases automation and reduces manualhandling of routine
paperwork. For the customer, the ATM is ubiquitous and alwaysavailable, handling routine
transactions whenever and wherever the customer [Link] software must be easy to use and
convenient so that customers will use it in preferenceto bank tellers. It must be reliable and secure
since it will be handling money.
■ Where will it be used? ATM software has become essential to financial [Link]
take it for granted that a bank will have an ATM machine. ATM machinesare available at many
stores, sporting events, and other locations throughout the world.
■ When is it needed? Any software development effort is a financial proposition. The investmentin
development ultimately leads to a revenue stream. From an economic perspective,it is desirable to
minimize the investment, maximize the revenue, and realizerevenue as soon as possible. Thoughtful
modeling and OO techniques are conducive tothis goal.
■ Why is it needed? There are many reasons why a vendor might decide to build a softwareproduct.
If other companies are making money with similar products, there is aneconomic incentive to
participate. A novel product could outflank competitors and leadto premium pricing. Businesses
commission internal efforts for technology that is difficultto buy and critical to them.
■ How will it work? We will adopt a three-tier architecture to separate the user interfacefrom
programming logic, and programming logic from the database. In reality, the architectureis n-tier,
20
because there can be any number of intermediate programming levelscommunicating with each
other.

6. Preparing a Problem Statement

Once you have raw idea by answering the high-level questions, you are readyto write a requirements
statement.
Requirements describe how a system behaves from the user’s point of [Link] example,some
requirements for a car are that when you press on the accelerator pedal, the cargoes faster, and when
you step on the brake, the car slows down.
 Requirements defines the decisions on system design. If you separate requirements from
design decisions, you can notchange a design.
 The problem statement should state what is to be done and nothow it is to be implemented.
 It should be a statement of needs, not a proposal for a systemarchitecture.
 The requestor should avoid describing system internals, as this restricts
developmentflexibility.
 Software engineering standards, such as modular construction,design for testability, and
provision for future extensions, should be proper.

The ATM Case Study

Figure shows a problem statement for an automated teller machine (ATM) [Link] the
software to support a computerized banking network including both human cashiersand automatic
teller machines (ATMs) to be shared by a consortium of banks. Each bankprovides its own
computer to maintain its own accounts and process transactions againstthem. Cashier stations are
owned by individual banks and communicate directly with theirown bank’s computers. Human
cashiers enter account and transaction [Link] teller machines communicate with a central
computer that clears transactions

with the appropriate banks. An automatic teller machine accepts a cash card, interactswith the user,
communicates with the central system to carry out the transaction, dispensescash, and prints
receipts. The system requires appropriate recordkeeping and security provisions.

21
The system must handle concurrent accesses to the same account [Link] banks will provide
their own software for their own computers; you are to designthe software for the ATMs and the
network. The cost of the shared system will be apportionedto the banks according to the number of
customers with cash cards.

Domain and Application Analysis

Domain analysis, the next stage of development, is concerned with developing a precise, concise,
and understandable model of the real world. Before building anything complex,the builder must
understand the requirements. During analysis, we build models and begin to understandthe
requirements [Link] build a domain model, you must interview business experts, examine
requirements statements, and scrutinize related artifacts.

7. Class model
You must perform the following steps to construct a domain class model.
 Find classes.
 Prepare a data dictionary.
 Find associations.
 Find attributes of objects and links.
 Organize and simplify classes using inheritance.
 Verify that access paths exist for likely queries.
 Iterate and refine the model.
 Reconsider the level of abstraction.

22
  Group classes into packages.

7.1 Finding Classes

Allclasses must be related to the application domain; avoid computer implementation constructs,
such as linked lists and subroutines. For example, in the statement “a reservation system to sell
ticketsto performances at various theaters” tentative classes would be Reservation, System,
Ticket,Performance, and Theater. Don’t operate blindly. The idea is to capture concepts;not all
nouns are concepts, and concepts are also expressed in other parts of speech.
ATM example. ForATM problem statement the tentative classes will be:

Now discard unnecessary and incorrect classes

 Redundant classes. If two classes express the same concept, you should keep the
mostdescriptive name. ATM example. Customer and User are redundant; we retain
Customer because itis more descriptive.
 ■ Irrelevant classes. If a class has little or nothing to do with the problem, eliminate [Link]
example. Apportioning Cost is outside the scope of the ATM software.

23
  ■ Vague classes. A class should be specific. Some tentative classes may have ill-
definedboundaries or be too broad in [Link] example. RecordkeepingProvisionis vague
and is handled by Transaction.
 Operations. If a name describes an operation and not manipulated in its own right, then it is
not a class. For example, a telephone call is a sequence of actions. If we are simply building
telephones, then Call is part of the state model and not a class.
 Roles. The name of a class should reflect its nature and not a role that it plays. For example,
Owner would be a poor name for a class in a car manufacturer’s database. What if a list of
drivers is added later? What about persons who lease cars? The proper class is Person (or
possibly Customer), which assumes various different roles, such as owner, driver, and lessee.
 Derived classes. As a general rule, omit classes that can be derived from other classes.

8.2 Preparing a Data Dictionary

Prepare a data dictionary for all modeling elements. Write a paragraph precisely describing each
class. Describe the scope of the class within the current problem, including any assumptions or
restrictions on its use. The data dictionary also describes associations, attributes, operations, and
enumeration values. Figure shows a data dictionary for the classes in the ATM problem.
Account—a single account at a bank. Accountsmay be of various types, such as checking
or savings. A customer can holdmore than one account.
ATM—a station that allows customers to do transactions. The ATM interacts with the
customer to gather transaction information,sends the transaction information to the
central computer for validationand processing, and dispenses cash to the user. We assume
that an ATM need notoperate independently.
Bank—a financial institution that holds accounts for customers and issues cash
cards authorizing access.
BankComputer—the computer owned by a bank that interfaces with the ATM network
and the bank’s own cashier stations. A bank may have its own internal computers
to process accounts, but we are concerned only with the one that talks to the ATM
network.
CashCard—a card assigned to a bank customer that authorizes access of accounts
using an ATM machine. Each card contains a bank code and a card number. The
bank code uniquely identifies the bank within the consortium. The card number
determines
the accounts that the card can access. A card does not necessarily access
all of a customer’s accounts. Each cash card is owned by a single customer, but multiple
copies of it may exist, so the possibility of simultaneous use of the same card
from different machines must be considered.
Cashier—an employee of a bank who is authorized to enter transactions into cashier
stations and accept and dispense cash and checks to customers. Transactions,
cash, and checks handled by each cashier must be logged and properly accounted
for.
CashierStation—a station on which cashiers enter transactions for customers.

24
Cashiers dispense and accept cash and checks; the station prints receipts. The cashier
station communicates with the bank computer to validate and process the transactions.
CentralComputer—a computer operated by the consortium that dispatches transactions
between the ATMs and the bank computers. The central computer validates
bank codes but does not process transactions directly.
Consortium—an organization of banks that commissions and operates the ATM network.
The network handles transactions only for banks in the consortium.
Customer—the holder of one or more accounts in a bank. A customer can consist of
one or more persons or corporations; the correspondence is not relevant to this problem.
The same person holding an account at a different bank is considered a different
customer.
Transaction—a single integral request for operations on the accounts of a single
customer. We specified only that ATMs must dispense cash, but we should not preclude
the possibility of printing checks or accepting cash or checks. We may also
want to provide the flexibility to operate on accounts of different customers, although
it is not required yet.

Figure: Data dictionary for ATM classes.

8.3 Find associations.

Now discard unnecessary and incorrect associations, using the following criteria.
■ Associations between eliminated classes. If you have eliminated one of the classes
in the association, you must eliminate the association.

■ Irrelevant or implementation associations. Eliminate any associations that are outside

the problem domain.

8. State model

9. Interaction model,

[Link] the analysis

25