Classification

 Classification is a characteristic of all scientific endeavors. Classification provides a

way of hierarchically organizing concepts to support our understanding better.
 Classification is relevant to all aspects of OO design, helping us generalize and
specialize classes and form meaningful aggregations.

Difficulty of Classification

 Classification is hard!
 Linnaeus is the prototypical classifier, responsible for the taxonomy of living
organisms. He developed the concepts of genus and species to help us categorize plants
and animals. Linnaeus used properties he could directly observe, such as fruit and leaf
shape. Modern work has used concepts from evolutionary theories to determine
classification, rather than merely considering structural organization.
 One must not forget that in this and other classification efforts, that classification is not
carried out in some purely rational objective sense. We must have a reason for
classifying, and that reason will affect the results of our classification task.
 Classification over time involves iteration and incremental refinement. The same is true
of software engineering processes.

Identifying Classes and Objects

 The following three types of classification are generally employed:

o Classical Categorization
o Conceptual Clustering
o Prototype Theory

Classical and Modern Approaches

Classical Categorization

 The classical categorization approach comes initially from Plato's concept of the ideals.
This philosophical concept captures the idea that categories are specified by an
objectively determinable collection of properties that characterize each of the elements
of the category. Each object sharing the properties is in the category and all objects in
the category share the property.
 Classical categorization was accepted as the one, true method of categorization until
nearly this century during which time it was discovered that many of the categories we
use every day do not satisfy the strict constraints of sharing a common set of properties.
Not all birds fly, some chairs are purely ornamental and no one will ever sit in such a
chair.
Conceptual Clustering

 Such categories are formed by developing conceptual descriptions (not strict

properties) and then classifying entities according to those descriptions. Consider the
class of fair judges.
Prototype Theory

 The concept behind prototype theory is that a category can be specified by

some best examples of the category, and then contains members related by some
principle to the best members.
 For example, the best prototype of the category mother would be a married woman
with a child or children, no job outside the home, who is the birth mother of the
children, and is their primary caregiver. This explains why sentence such as

She's a mother, but she has a job.

sound reasonable, while

She's a mother, but she doesn't have a job.

sounds somewhat odd to us. Likewise, sentences such as

I just can't be a mother to my children.

when spoken by a biological mother makes sense to us, indicating that the
category mother has many different kinds of interpretations.

 The pragmatic and cultural nature of these categories, likewise distinguishes them from
the Platonic ideal categories which are presumed to be completely objective in nature.
 In prototype categorization the relation between the central elements and the non-
central ones may be giving by a generative rule, by a connective principal, or by some
other means.

Object-Oriented Analysis

 In Analysis, we try to discover the classes and objects that comprise the vocabulary of
the problem domain. A number of approaches have been used in carrying out this task.
Classical Approaches

 These derive from classical categorization.

 Sources include
o tangible things
o roles
o events, and interactions

which can be identified by

o nouns
o adjectives
o verbs

in the requirements specification.

  Some of the nouns will be people, places, things, organizations, or concepts.
 Other sources of potential objects include other outside agents, devices, records of
events, locations, and organizational units.
 Any classes identified in this way may be generalized by grouping them together.
Behavior Analysis

 The behavior analysis is mor akin to conceptual clustering and consists of classifying
objects according to common behavior.
 Centering on the idea of responsibilities (or the services an object provides for all
contracts it supports) conveys the conceptual cluster basis.
 The notion of a function point or single end-user transaction is often used to
characterize the analysis view of responsibilities.
Domain Analysis

 The goal in domain analysis is to find classes and objects that are common to all
systems dealing with problems in the same domain, then consider those which are
specific to the problem at hand.
 One benefit of domain analysis is that it supports the possibility of generating more
general classes which can be reused in a variety of specific problm instances.
 Domain analysis requires a domain expert. Booch notes "It is truly amazing to see what
a little bit of domain knowledge can do to assist a developer in making intelligent
design decisions.
Use-Case Analysis

 Introduced by Jacobson
 A use-case is a "particular form or pattern or exemplar of usage, a scenario that begins
with some user of the system initiating some transaction or sequence of interrelated
events.
 In analysis, we may enumerate the use-cases that are fundamental to the operation of
the system.
 As development proceeds, the team walks through each scenario identifying the
participant objects and their responsibilities, and the collaborations in which these
objects participate.
CRC Cards

 CRC (Class/Responsibilities/Collaborators) cards provide a concrete product of

analysis of scenarios, and other analyses, by recording each class's responsibilities and
those classes with which it collaborates.
 Different arrangements of the cards can be used to analyze dynamic message flow,
static semantics, generalization/specialization, and other views of a system. The value
in having physical cards is that it permits easy spatial rearrangement of the
representations of the classes.
Informal English Descriptions
  A strikingly simple, yet meaningful approach to analysis is to use informal natural
language descriptions and exploit linguistic categories to provide design categories.
 In employing Abbott's approach in an O-O setting, one identifies nouns with objects
and classes, and verbs with operations.
 This approach provides a good initial method of analysis and helps in the formation of
a Data Dictionary.
Structured Analysis

 Structured analysis is a technique that has been used to develop programs using
concepts of structured programming, which, as we have previously noted has a
procedural basis.
 The SA method typically describes a system with dataflow diagrams which result from
analysis activities similar to the O-O methods described above.
 O-O elements can be retrieved from SA designs by scavenging the data dictionary for
objects, and by analyzing the dataflow diagrams to identify
o external entities
o data stores
o control stores
o control transformations

Iterative and incremental development (IID)

 Difficulty Level : Basic
 Last Updated : 02 Nov, 2020
As the name indicates, Iterative and incremental development (IID) is a model that is an
incremental model that is developed in multiple cycles of iterations. Project is started with a
comparatively small task or component and increments are made in each cycle of the iterations
until desired product is reached. During this process, developers have advantage of evaluating
and testing components at each stage and gaining information that would be useful at end stages
as well. This knowledge is used to also improve design of final product.
Iteration includes update and execution of cycles are to be basic, direct, and particular,
supporting overhaul at that stage or as an errand added to task control list. Degree of
configuration detail isn’t directed by iterative methodology.
In a low processing iterative project, code may speak to significant source of documentation of
framework; nonetheless, in a basic iterative task, a conventional software design document
might be utilized. Examination of a cycle depends on client input, and program investigation
offices accessible. It includes investigation of structure, seclusion, convenience, unwavering
quality, effectiveness, and accomplishment of objectives. Undertaking control list is changed
considering investigation results.
Phases in IID :
As development is incremental and iterative, different functions are applied in different phases.
According to prerequisites of organization, at each phase, functionalities are implemented.
There are four phases in IID :
 Inception –
In this phase reorganization of project scope, prerequisites, and risks at an elevated level yet
in enough detail that work can be assessed are done.
 Elaboration –
In this phase, conveying a working structure that mitigates top dangers and satisfies non-
functional necessities is done.
 Construction –
In this phase, functionalities are incremented gradually with codes for functional
requirements. Whole architecture is built in this phase.
 Transition –
In this phase, project is transitioned into production and then deployment.
In this cyclic process, architects work one iteration early than testers, which creates a flow in
workspace. Each phase is one or more iterations long.
Advantages of IID :
 Each delivery is an item increment, with goal that client will have a working item within
reach constantly.
 You can create organized prerequisites first.
 If the requirements are changed midway, new requirements can be augmented without any
issue.
 Clients get significant functionality faster.
 Client can give input to every item increment, accordingly maintaining a strategic distance
from differences toward finish of improvement.
 Brings down introductory delivery cost.
 Initial item delivery is quicker.
Disadvantages of IID :
 Requires the early meaning of a total and completely functional framework to permit the
meaning of additions.
 Absolute expense of the total framework isn’t lower.
 Requires an effective plan to guarantee incorporation of the necessary functionalities and
arrangement for changes later.
 Requires successful arranging of cycles.
 Very characterized module interfaces are needed, as some are made some time before others
are created.
Where and when to use IID model ?
IID can be used when :
 There is a requirement to get fundamental functionality conveyed quick.
 There is new advancement in technology to implement a project.
 Prerequisites are organized.
 Vast majority of requirements are known in advance however are required to advance after
some time.
 Domain is new to working group.
 There is a venture with extensive improvement plans.

In an Iterative Incremental model, initially, a partial implementation of a total system is constructed so

that it will be in a deliverable state. Increased functionality is added. Defects, if any, from the prior
delivery are fixed and the working product is delivered. The process is repeated until the entire product
development is completed. The repetitions of these processes are called iterations. At the end of every
iteration, a product increment is delivered.

Iterative Incremental Model – Strengths

The advantages or strengths of Iterative Incremental model are −
 You can develop prioritized requirements first.
 Initial product delivery is faster.
 Customers gets important functionality early.
 Lowers initial delivery cost.
 Each release is a product increment, so that the customer will have a working product at hand all
the time.
 Customer can provide feedback to each product increment, thus avoiding surprises at the end of
development.
 Requirements changes can be easily accommodated.

Iterative Incremental Model – Weaknesses

The disadvantages of the Iterative Incremental model are −
 Requires effective planning of iterations.
 Requires efficient design to ensure inclusion of the required functionality and provision for
changes later.
 Requires early definition of a complete and fully functional system to allow the definition of
increments.
 Well-defined module interfaces are required, as some are developed long before others are
developed.
  Total cost of the complete system is not lower.

When to Use Iterative Incremental Model?

Iterative Incremental model can be used when −
 Most of the requirements are known up-front but are expected to evolve over time.
 The requirements are prioritized.
 There is a need to get the basic functionality delivered fast.
 A project has lengthy development schedules.
 A project has new technology.
 The domain is new to the team.

Object Oriented Analysis and Design

 Difficulty Level : Medium
 Last Updated : 07 Apr, 2020
Object Oriented Analysis (OOA):
Object Oriented Analysis (OOA) is the first technical activity performed as part of object oriented
software engineering. OOA introduces new concepts to investigate a problem. It is based in a set
of basic principles, which are as follows-
1. The information domain is modeled.
2. Behavior is represented.
3. Function is described.
4. Data, functional, and behavioral models are divided to uncover greater detail.
5. Early models represent the essence of the problem, while later ones provide implementation
details.
The above notes principles form the foundation for the OOA approach.
Object Oriented Design (OOD):
An analysis model created using object oriented analysis is transformed by object oriented design
into a design model that works as a plan for software creation. OOD results in a design having
several different levels of modularity i.e., The major system components are partitioned into
subsystems (a system level “modular”), and data their manipulation operations are encapsulated
into objects (a modular form that is the building block of an OO system.).
In addition, OOD must specify some data organization of attributes and a procedural description
of each operation.
Shows a design pyramid for object oriented systems. It is having the following four layers.
1. The Subsystem Layer :
It represents the subsystem that enables software to achieve user requirements and implement
technical frameworks that meet user needs.

2. The Class and Object Layer :

It represents the class hierarchies that enable the system to develop using generalization and
specialization. This layer also represents each object.

3. The Message Layer :

It represents the design details that enable each object to communicate with its partners. It
establishes internal and external interfaces for the system.

4. The Responsibilities Layer :

It represents the data structure and algorithmic design for all the attributes and operations for
each object.
The Object Oriented design pyramid specifically emphasizes specific product or system design.
Note, however, that another design layer exists, which forms the base on which the pyramid rests.
It focuses on the core layer the design of the domain object, which plays an important role in
building the infrastructure for the Object Oriented system by providing support for
human/computer interface activities, task management.
UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system.
The behavioral diagrams are categorized as follows: use case diagrams, interaction diagrams, state–chart
diagrams, and activity diagrams.

Use Case Model

Use case
A use case describes the sequence of actions a system performs yielding visible results. It shows the
interaction of things outside the system with the system itself. Use cases may be applied to the whole
system as well as a part of the system.

Actor
An actor represents the roles that the users of the use cases play. An actor may be a person (e.g. student,
customer), a device (e.g. workstation), or another system (e.g. bank, institution).
The following figure shows the notations of an actor named Student and a use case called Generate
Performance Report.

Use case diagrams

Use case diagrams present an outside view of the manner the elements in a system behave and how they
can be used in the context.
Use case diagrams comprise of −

 Use cases
 Actors
 Relationships like dependency, generalization, and association
Use case diagrams are used −
 To model the context of a system by enclosing all the activities of a system within a rectangle and
focusing on the actors outside the system by interacting with it.
 To model the requirements of a system from the outside point of view.
Example
Let us consider an Automated Trading House System. We assume the following features of the system −
 The trading house has transactions with two types of customers, individual customers and
corporate customers.
  Once the customer places an order, it is processed by the sales department and the customer is
given the bill.
 The system allows the manager to manage customer accounts and answer any queries posted by
the customer.

Interaction Diagrams
Interaction diagrams depict interactions of objects and their relationships. They also include the
messages passed between them. There are two types of interaction diagrams −

 Sequence Diagrams
 Collaboration Diagrams

Interaction diagrams are used for modeling −

 the control flow by time ordering using sequence diagrams.
 the control flow of organization using collaboration diagrams.

Sequence Diagrams
Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to time.
Notations − These diagrams are in the form of two-dimensional charts. The objects that initiate the
interaction are placed on the x–axis. The messages that these objects send and receive are placed along
the y–axis, in the order of increasing time from top to bottom.
Example − A sequence diagram for the Automated Trading House System is shown in the following
figure.
Collaboration Diagrams
Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send and
receive messages.
Notations − In these diagrams, the objects that participate in the interaction are shown using vertices.
The links that connect the objects are used to send and receive messages. The message is shown as a
labeled arrow.
Example − Collaboration diagram for the Automated Trading House System is illustrated in the figure
below.
State–Chart Diagrams
A state–chart diagram shows a state machine that depicts the control flow of an object from one state to
another. A state machine portrays the sequences of states which an object undergoes due to events and
their responses to events.
State–Chart Diagrams comprise of −

 States: Simple or Composite

 Transitions between states
 Events causing transitions
 Actions due to the events
State-chart diagrams are used for modeling objects which are reactive in nature.
Example
In the Automated Trading House System, let us model Order as an object and trace its sequence. The
following figure shows the corresponding state–chart diagram.

Activity Diagrams
An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state
machine. Activities result in actions which are atomic operations.
Activity diagrams comprise of −

 Activity states and action states

 Transitions
 Objects
Activity diagrams are used for modeling −

 workflows as viewed by actors, interacting with the system.

 details of operations or computations using flowcharts.
Example
The following figure shows an activity diagram of a portion of the Automated Trading House System.
Domain analysis is the process by which a software engineer learns background information. He or she has to learn
sufficient information so as to be able to understand the problem and make good decisions during requirements
analysis and other stages of the software engineering process. The word ‘domain’ in this case means the general field
of business or technology in which the customers expect to be using the software.
Some domains might be very broad, such as ‘airline reservations’, ‘medical diagnosis’, and
‘financial analysis’. Others are narrower, such as ‘the manufacturing of paint’ or ‘scheduling
meetings’. People who work in a domain and who have a deep knowledge of it (or part of it),
are called domain experts. Many of these people may become customers or users.
To perform domain analysis, you gather information from whatever sources of information are available: these
include the domain experts; any books about the domain; any existing software and its documentation, and any other
documents he or she can find. The interviewing, brainstorming and use case analysis techniques discussed later in this
chapter can help with domain analysis. Object oriented modelling, discussed in the next chapter, can also be of
assistance.
As a software engineer, you are not expected to become an expert in the domain; nevertheless,
domain analysis can involve considerable work. The following benefits will make this work
worthwhile:
 
•    Faster development: You will be able to communicate with the stakeholders more effectively, hence you will be
able to establish requirements more rapidly. Having performed domain analysis will help you to focus on the most
important issues.
•    Better system: Knowing the subtleties of the domain will help ensure that the solutions you adopt will more
effectively solve the customer’s problem. You will make fewer mistakes, and will know which procedures and
standards to follow. The analysis will give you a global picture of the domain of application; this will lead to better
abstractions and hence improved designs.
•    Anticipation of extensions: Armed with domain knowledge, you will obtain insights into emerging trends and
you will notice opportunities for future development. This will allow you  to build a more adaptable system.
 
It is useful to write a summary of the information found during domain analysis. The process
of organizing and writing this summary can help you gain a better grasp of the knowledge; the
resulting document can help educate other software engineers who join the team later.

Use-Case Model
The Use-case model is defined as a model which is used to show how users interact with the system in
order to solve a problem. As such, the use case model defines the user's objective, the interactions
between the system and the user, and the system's behavior required to meet these objectives.

Various model elements are contained in use-case model, such as actors, use cases, and the association
between them.

We use a use-case diagram to graphically portray a subset of the model in order to make the
communication simpler. There will regularly be a numerous use-case diagram which is related to the
given model, each demonstrating a subset of the model components related to a specific purpose. A
similar model component might be appearing on a few use-case diagrams; however, each use-case should
be consistent. If, in order to handle the use-case model, tools are used then this consistency restriction is
automated so that any variations to the component of the model (changing the name, for instance) will be
reflected automatically on each use-case diagram, which shows that component.

Packages may include a use-case model, which is used to organize the model to simplify the analysis,
planning, navigation, communication, development and maintenance.

46.4M

749

Hello Java Program for Beginners

Various use-case models are textual and the text captured in the use-case specifications, which are linked
with the element of every use-case model. The flow of events of the use case is described with the help of
these specifications.

The use-case model acts as an integrated thread in the development of the entire system. The use-case
model is used like the main specification of the system functional requirements as the basis for design and
analysis, as the basis for user documentation, as the basis of defining test cases, and as an input to
iteration planning.

Origin of Use-Case
Nowadays, use case modeling is frequently connected with UML, in spite of the fact that it has been
presented before UML existed. Its short history is:

o Ivar Jacobson, in the year 1986, originally formulated textual and visual modeling methods to specify use
cases.
o And in the year 1992, his co-authored book named Object-Oriented Software Engineering - A Use Case
Driven Approach, assisted with promoting the strategy for catching functional requirements, particularly in
software development.
Components of Basic Model
There are various components of the basic model:

1. Actor
2. Use Case
3. Associations

Actor
Usually, actors are people involved with the system defined on the basis of their roles. An actor can be
anything such as human or another external system.

Use Case
The use case defines how actors use a system to accomplish a specific objective. The use cases are
generally introduced by the user to meet the objectives of the activities and variants involved in the
achievement of the goal.

Associations
Associations are another component of the basic model. It is used to define the associations among actors
and use cases they contribute in. This association is called communicates-association.

Advanced Model Components

There are various components of the advanced model:

1. Subject
2. Use-Case Package
3. Generalizations
4. Generalizations
5. Dependencies

Subject
The subject component is used to represent the boundary of the system of interest.

Use-Case Package
We use the model component in order to structure the use case model to make simpler the analysis,
planning, navigation, and communication. Suppose there are various actors or use cases. In that case, we
can also use use-case packages in order to further structure the use-case model in much the similar way
we use directories or folders to organize the information on our hard-disk.

For various reasons, we divide the use-case model into the use-case packages, containing:
 o To help parallel development by partitioning the problem into bite-sized parts.
o To improve communication with various stakeholders by making packaging containing actors, use cases
and related to the specific stakeholder.

Generalizations
Generalizations mean the association between the actors in order to help re-use of common properties.

Dependencies
In UML, various types of dependencies are defined between use cases. In particular, <<include>> and
<<extend>>.

We use <<include>> dependency to comprise shared behavior from an included use case into a base use
case to use common behavior.

We use <<extend>> dependency to include optional behavior from an extended use-case into an extended
use case.

How to Draw a Use-Case Diagram?

If we want to draw a use case diagram in UML first, we must study the complete system appropriately.
We need to find out every function which is offered by the system. When we find out all the system's
functionalities then we convert these functionalities into a number of use cases, and we use these use-
cases in the use case diagram.

A use case means essential functionality of any working system. When we organize the use cases, then
next we need to enlist the numerous actors or things that will collaborate with the system. These actors
are used to implement the functionality of a system. Actors can be someone or something. It can likewise
be a private system's entity. The actors should be pertinent to the functionality or a system in which the
actors are interacting.

When we enlist the use cases and actors, then next, we need to find the relationship of a specific actor
with the system or a use case. An actor should find the total number of ways in order to cooperate with
the system. One actor can interact with the numerous use cases simultaneously, or it may interact with the
multiple-use cases concurrently.

We have to follow the following rules while drawing use-case for any framework:

o The use case name and actor name should be meaningful and related to the system.
o The actor's interaction with the use case should be well-described and in a comprehensible manner.
o Use annotations wherever they are essential.
o If the actor or use case has many relationships, then display only important interactions.

When to Use a Use-Case Diagram?

The use-case diagram is an extraordinary system's functionality that is accomplished by a client. The
objective of use-case diagram is to capture the system's key functionalities and visualize the interactions
of different thinkings known as actors with the use case. It is the basic use of use-case diagram.

With the help of the use-case diagram, we can characterize the system's main part and flow of work
among them. In the use-case, the implementation of details is hidden from external use, and only the flow
of the event is represented.

Using use-case diagrams, we can detect the pre-and post-conditions after communication with the actor.
We can determine these conditions using several test cases.

Generally, the use-cases diagram is used for:

o Examining the system's requirements.

o Capturing the system's Functionalities.
o We use use-case diagram in order to modeling the general idea behind the system.
o System's Forward and reverse engineering using several test cases.
o Complex visual designing of software.

Use cases are planned to convey wanted functionality so that the exact scope of use case can differ based
on the system and the purpose of making the UML model.

Tips for Drawing a Use-Case Diagram

There are various tips for drawing a use-case diagram:

o It must be complete.
o It must be simple.
o The use-case diagram must show each and every interaction with the use case.
o It is must that the use-case should be generalized if it is large.
o At least one system module must be defined in the use case diagram.
o When there are number of actors or use-cases in the use-case diagram, only the significant use-cases must
be represented.
o The use-case diagrams must be clear and easy so that anyone can understand them easily.

Importance of Use-Case Diagram

Use Cases have been broadly used over the last few years. There are various benefits of the use-case
diagram:

o Use-case diagram provides an outline related to all components in the system. Use-case diagram helps to
define the role of administrators, users, etc.
 o The use-Case diagram helps to provide solutions and answers to various questions that may pop up if you
begin a project unplanned.
o It helps us to define the needs of the users extensively and explore how it will work.

Basic Use-Case Diagram Symbols and Notations

There are following use-case diagram symbols and notations:

System
With the help of the rectangle, we can draw the boundaries of the system, which includes use-cases. We
need to put the actors outside the system's boundaries.

Use-Case
With the help of the Ovals, we can draw the use-cases. With the verb we have to label the ovals in order
to represent the functions of the system.

Actors
Actors mean the system's users. If one system is the actor of the other system, then with the actor
stereotype, we have to tag the actor system.
Relationships
With the simple line we can represent relationships between an actor and use cases. For relationships
between use-case, we use arrows which are labeled either "extends" or "uses". The "extends" relationship
shows the alternative options under the specific use case. The "uses" relationship shows that single use-
case is required to accomplish a job.

Guidelines for Better Use-Cases

With regards to examine the system's requirements, use-case diagrams are another one to one. Use-cases
are simple to understand and visual. The following are some guidelines that help you to make better use
cases that are appreciated by your customers and peers the same.

Generally, the use-case diagram contains use-cases, relationships, and actors. Systems and boundaries
may be included in the complex larger diagrams. We'll talk about the guidelines of the use-case diagram
on the basis of the objects.

Do not forget that these are the use case diagram's guidelines, not rules of the use-case diagram.

Actors
 o The actor's name should be meaningful and relevant to the business
If the use-case interacting with the outside organization, then we have to give the actor's name with the
function instead of the organization name, such as Airline company is better than the PanAir).
o Place inheriting actors below the parent actor
We have to place the inheriting actors below the parent actor because it makes the actors more readable and
easily highlights the use-cases, which are exact for that actor.
o External Systems are actors
If send-email is our use-case and when the use-case interrelates with the email management software, then
in this case, the software is an actor to that specific user-case.

Use-Cases

o The name of the use-case begins with a verb

The use-case models action, so the name of the use-case must start with a verb.
o The name of the use-case must be descriptive
The use-case is created to provide more information to others who are looking at a diagram, such as instead
of "Print," "print Invoice is good.
o Put the use-cases to the right of the included use-cases.
In order to add clarity and enhance readability, we have to place the included use-cases to the right of the
invoking use-cases.
o Place inheriting use-case below the parent use-case
In order to enhance the diagram's readability, we have to place the inheriting use-case below the parent use-
case.

Systems/Packages

o Give descriptive and meaningful names to these objects.

o Use them carefully and only if needed.

Relationships
o When we are using <<extend>> arrow, points to the base use-case.
o When we are using <<include>> then arrow points to the comprised use-case.
o Actor and use-case relationship do not display arrows.
o <<extend>> may have an optional extension condition.
o <<include>> and <<extend>> both are shown as dashed arrows.

Use-Case Examples
Use-Case Example-Association Link
In this use-case diagram, we show a group of use cases for a system which means the relationship among
the use-cases and the actor.

Use-Case Example-Include Relationship

In order to add additional functionality that is not specified in the base use-case, we use to include
relationship. We use it to comprise the general behavior from an included use case into a base case so that
we can support the reuse general behavior.

Use-Case Example-Extend Relationship

With the help of the extend relationship, we can show the system behavior or optional functionality. We
use <<extend>> relationship in order to comprise optional behavior from an extending use-case in an
extended use-case. For example, the below diagram of the use-case displays an extend connector and an
extension point "Search".

Use-Case Example-Generalization Relationship

In the generalization relationship, the child use-case can inherit the meaning and behavior of the parent
use-case. The child use-case is able to override and adds the parent's behavior. The below diagram is an
example of generalization relationship in which two generalization connector is connected among three
use-cases.

Use-Case Diagram-Vehicle Sales Systems

The below diagram displays an instance of a use-case diagram for a vehicle system. As we can also see, a
system as much as one vehicle sales system contains not in excess of 10 use-cases, and it is the delicacy
of use-case modeling.
The use of include and extend is also displayed by the use-case model. In addition, there are associations
that link between the use-case and actors.

Use-Case Diagram-Student Management System

The below figure shows the working of the student management system:
In the above use-case diagram of the student management system, we have two actors and five use-cases.
The name of the actors is Student and Teacher. The use-cases represent the definite functionality of the
student management system. Every actor interacts with a specific use-case. The student actor is able to
check the test marks, time-table and attendance. These are only 3 interactions that can be performed by
the student actor; however various use-cases are also remaining in the system.

It is not must that every actor has to interact with each and every use-case, but it can happen.

A Class Responsibility Collaborator (CRC) model (Beck & Cunningham 1989; Wilkinson 1995; Ambler 1995) is a collection
of standard index cards that have been divided into three sections, as depicted in Figure 1. A class represents a collection of
similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts
with to fulfill its responsibilities. Figure 2 presents an example of two hand-drawn CRC cards.

Figure 1. CRC Card Layout.

Figure 2. Hand-drawn CRC Cards.

Although CRC cards were originally introduced as a technique for teaching object-oriented concepts, they have also been
successfully used as a full-fledged modeling technique. My experience is that CRC models are an incredibly effective tool for
conceptual modeling as well as for detailed design. CRC cards feature prominently in eXtreme Programming (XP) (Beck
2000) as a design technique. My focus here is on applying CRC cards for conceptual modeling with your stakeholders.

A class represents a collection of similar objects. An object is a person, place, thing, event, or concept that is relevant to the
system at hand. For example, in a university system, classes would represent students, tenured professors, and seminars. The
name of the class appears across the top of a CRC card and is typically a singular noun or singular noun phrase, such
as Student, Professor, and Seminar. You use singular names because each class represents a generalized version of a singular
object. Although there may be the student John O'Brien, you would model the class Student. The information about a student
describes a single person, not a group of people. Therefore, it makes sense to use the name Student and not Students. Class
names should also be simple. For example, which name is better: Student or Person who takes seminars?

A responsibility is anything that a class knows or does. For example, students have names, addresses, and phone numbers.
These are the things a student knows. Students also enroll in seminars, drop seminars, and request transcripts. These are the
things a student does. The things a class knows and does constitute its responsibilities. Important: A class is able to change the
values of the things it knows, but it is unable to change the values of what other classes know.

Sometimes a class has a responsibility to fulfill, but not have enough information to do it. For example, as you see in Figure
3 students enroll in seminars. To do this, a student needs to know if a spot is available in the seminar and, if so, he then needs
to be added to the seminar. However, students only have information about themselves (their names and so forth), and not
about seminars. What the student needs to do is collaborate/interact with the card labeled Seminar to sign up for a seminar.
Therefore, Seminar is included in the list of collaborators of Student.

Figure 3. Student CRC card.

Collaboration takes one of two forms: A request for information or a request to do something. For example, the
card Student requests an indication from the card Seminar whether a space is available, a request for information. Student then
requests to be added to the Seminar, a request to do something. Another way to perform this logic, however, would have been
to have Student simply request Seminar to enroll himself into itself. Then have Seminar do the work of determining if a seat is
available and, if so, then enrolling the student and, if not, then informing the student that he was not enrolled.

So how do you create CRC models? Iteratively perform the following steps:

 Find classes. Finding classes is fundamentally an analysis task because it deals with identifying the building blocks
for your application. A good rule of thumb is that you should look for the three-to-five main classes right away, such
as Student, Seminar, and Professor in Figure 4. I will sometimes include UI classes such as Transcript and Student
Schedule, both are reports, although others will stick to just entity classes. Also, I'll sometimes include cards
representing actors when my stakeholders are struggling with the concept of a student in the real world (the actor)
versus the student in the system (the entity).
 Find responsibilities. You should ask yourself what a class does as well as what information you wish to maintain
about it. You will often identify a responsibility for a class to fulfill a collaboration with another class.
 Define collaborators. A class often does not have sufficient information to fulfill its responsibilities. Therefore, it
must collaborate (work) with other classes to get the job done. Collaboration will be in one of two forms: a request for
information or a request to perform a task. To identify the collaborators of a class for each responsibility ask yourself
"does the class have the ability to fulfill this responsibility?". If not then look for a class that either has the ability to
fulfill the missing functionality or the class which should fulfill it. In doing so you'll often discover the need for new
responsibilities in other classes and maybe even the need for a new class or two.
  Move the cards around. To improve everyone's understanding of the system, the cards should be placed on the table
in an intelligent manner. Two cards that collaborate with one another should be placed close together on the table,
whereas two cards that don't collaborate should be placed far apart. Furthermore, the more two cards collaborate, the
closer they should be on the desk. By having cards that collaborate with one another close together, it's easier to
understand the relationships between classes.

Figure 4. CRC Model.

How do you keep your CRC modeling efforts agile? By following the AM practice Model in Small Increments. The best way
to do this is to create a CRC model for a single requirement, such as a user story, business rule, or system use case, instead of
the entire collection of requirements for your system. Because CRC cards are very simple tools they are inclusive, enabling
you to follow AM's Active Stakeholder Participation practice.

It's important to recognize that a CRC model isn't carved in stone. When you evolve it into a UML class diagram, or perhaps
straight into code, you'll change the schema over time. Responsibilities will be reorganized, new classes will be introduced,
existing classes will disappear, and so on. This is what happens when you take an evolutionary approach to development.

Analysts use various tools to understand and describe the information system. One of the ways is using
structured analysis.

What is Structured Analysis?

Structured Analysis is a development method that allows the analyst to understand the system and its
activities in a logical way.
It is a systematic approach, which uses graphical tools that analyze and refine the objectives of an
existing system and develop a new system specification which can be easily understandable by user.
It has following attributes −
 It is graphic which specifies the presentation of application.
 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not depend on vendor or hardware.
 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development. They are −

 Data Flow Diagrams

 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of system in a graphical
form.
 It shows the flow of data between various functions of system and specifies how the current
system is implemented.
 It is an initial stage of design phase that functionally divides the requirement specifications down
to the lowest level of detail.
  Its graphical nature makes it a good communication tool between user and analyst or analyst and
system designer.
 It gives an overview of what data a system processes, what transformations are performed, what
data are stored, what results are produced and where they flow.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user wants a
notational language for communication. However, it requires a large number of iterations for obtaining
the most accurate and complete solution.
The following table shows the symbols used in designing a DFD and their significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that
differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows which It is implementation independent. It focuses only

functions are performed. on the flow of data between processes.

It provides low level details of hardware, It explains events of systems and data required by
software, files, and people. each event.

It depicts how the current system operates and It shows how business operates; not how the
how a system will be implemented. system can be implemented.
Context Diagram
A context diagram helps in understanding the entire system by one DFD which gives the overview of a
system. It starts with mentioning major processes with little details and then goes onto giving more
details of the processes with the top-down approach.
The context diagram of mess management is shown below.

Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the descriptions of all
DFD data elements that is, details and definitions of data flows, data stores, data stored in data stores,
and the processes.
A data dictionary improves the communication between the analyst and the user. It plays an important
role in building a database. Most DBMSs have a data dictionary as a standard feature. For example, refer
the following table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and avoiding the
problems in communication. A decision tree is a diagram that shows alternative actions and conditions
within horizontal tree framework. Thus, it depicts which conditions to consider first, second, and so on.
Decision trees depict the relationship of each condition and their permissible actions. A square node
indicates an action and a circle indicates a condition. It forces analysts to consider the sequence of
decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what other
combinations of conditions you can take for testing. It is a single representation of the relationships
between conditions and actions.
For example, refer the following decision tree −

Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise manner which is
easily understandable.
 It is useful in situations where the resulting actions depend on the occurrence of one or several
combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

  Condition Stub − It is in the upper left quadrant which lists all the condition to be checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be carried out to
meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to questions asked in
condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action resulting from
the answers to the conditions in the condition entry quadrant.
The entries in decision table are given by Decision Rules which define the relationships between
combinations of conditions and courses of action. In rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

Structured English
Structure English is derived from structured programming language which gives more understandable
and precise description of process. It is based on procedural logic that uses construction and imperative
sentences designed to perform operation for action.
 It is best used when sequences and loops in a program must be considered and the problem needs
sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential decision structures
and iterations.
For example, see the following sequence of actions −
if customer pays advance
then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if

Pseudocode
A pseudocode does not conform to any programming language and expresses logic in plain English.
 It may specify the physical programming logic without actual coding during and after the physical
design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your requirements −
 Use DFD at high or low level analysis for providing good system documentations.
 Use data dictionary to simplify the structure for meeting the data requirement of the system.
 Use structured English if there are many loops and actions are complex.
 Use decision tables when there are a large number of conditions to check and logic is complex.
 Use decision trees when sequencing of conditions is important and if there are few conditions to
be tested.

Key abstractions
 Key abstractions are the key concepts and abstractions that the system needs to handle. They are those
things that, without which, you could not describe the system.
 The requirements are good sources for key abstractions. These abstractions are often easily identified
because they represent things that are significant to the business. For example, Customer and Account are
typical key abstractions in the banking business.
 Each key abstraction should have a short description.  The are usually not described in detail as they will
change and evolve during the course of the project (as they are refined into actual design elements). 
 The value of defining the key abstractions (and any obvious relationships between them) is that they
establish a common understanding of the key concepts amongst the team, thereby enabling them to develop
a coherant solution that handles them consistently.
Identify Analysis Mechanisms:

 In order to better understand what an analysis mechanism is, we have to understand

what an architectural mechanism is.
 An architectural mechanism represents a common solution to a frequently encountered
problem. It may be patterns of structure, patterns of behavior, or both. Architectural
mechanisms are an important part of the "glue" between the required functionality of
the system and how this functionality is realized, given the constraints of the
implementation environment.
 Support for architectural mechanisms needs to be built in to the architecture.
Architectural mechanisms are coordinated by the architect. The architect chooses the
mechanisms, validates them by building or integrating them, verifies that they do the
job, and then consistently imposes them upon the rest of the design of the system.

 Architectural Mechanism Categories:

o Analysis mechanisms (conceptural): capture the key aspects of a solution in a
way that is implementation-independent. They either provide specific behaviors
to a domain-related class or component, or correspond to the implementation of
cooperation between classes and/or components. They may be implemented as a
framework.
 o Design mechanisms (concrete): are more concrete. They assume some details of
the implementation environment, but are not tied to a specific implementation
(as is an implementation mechanism).
o Implementation mechanisms (actual): specify the exact implementation of the
mechanism. Implementation mechanisms are bound to a certain technology,
implementation language, vendor, or other factor.
 Analysis mechanisms are used during analysis to reduce the complexity of analysis and
to improve its consistency by providing designers with a shorthand representation for
complex behavior.
 Sample Analysis Mechanisms:
o Persistency: A persistent object is one that logically exists beyond the scope of
the program that created it . The need to have object lifetimes that span use
cases, process lifetimes, or system shutdown and startup, defines the need for
object persistence. Persistence is a particularly complex mechanism. During
analysis we do not want to be distracted by the details of how we are going to
achieve persistence. This gives rise to a "persistence" analysis mechanism that
allows us to speak of persistent objects and capture the requirements we will
have on the persistence mechanism without worrying about what exactly the
persistence mechanism will do or how it will work.
o Communication (IPC and RPC): Examples of communication mechanisms
include inter-process communication (IPC) and inter-node communication
(a.k.a. remote process communication or RPC). RPC has both a communication
and a distribution aspect.
o Message routing
o Distribution
o Transaction management
o Process control and synchronization (resource contention)
o Information exchange, format conversion
o Security
o Error detection/handling/reporting
o Redundancy
o Legacy Interface
 Examples of Analysis Mechanism Characteristics:
o Persistency mechanism: For all classes whose instances may become persistent,
we need to identify:
 Granularity: Range of size of the persistent objects
 Volume: Number of objects to keep persistent
 Duration: How long to keep persistent objects
 Access mechanism: How is a given object uniquely identified and
retrieved?
  Access frequency: Are the objects more or less constant; are they
permanently updated?
 Reliability: Shall the objects survive a crash of the process, the processor;
the whole system?
o Inter-process communication mechanism: For all model elements that need to
communicate with objects, components, or services executing in other processes
or threads, we need to identify:
 Latency: How fast must processes communicate with another?
 Synchronicity: Asynchronous communication
 Size of message: A spectrum might be more appropriate than a single
number
 Protocol: flow control, buffering, and so on
o Legacy inter mechanism:
 Latency
 Duration
 Access mechanism
 Access frequency
o Security mechanism:
 Data granularity: Package-level, class-level, attribute level
 User granularity: Single users, roles/groups
 Security Rules: Based on value of data, on algorithm based on data, and
on algorithm based on user and data
 Privilege Types: Read, write, create, delete, perform some other operation
 The process for describing analysis mechanisms is:
o Collect all analysis mechanisms in a list: The same analysis mechanism may
appear under several different names across different use-case realizations, or
across different designers. For example, storage, persistency, database, and
repository might all refer to a persistency mechanism. Inter-process
communication, message passing, or remote invocation might all refer to an
inter-process communication mechanism.
o Draw a map of the client classes to the analysis mechanisms:
 o Identify characteristics of the analysis mechanisms: To discriminate across a
range of potential designs, identify the key characteristics used to qualify each
analysis mechanism. These characteristics are part functionality, part size, and
performance.
o Model using collaborations: Once all of the analysis mechanisms are identified
and named, they should be modeled through the collaboration of a "society of
classes." Some of these classes do not directly deliver application functionality,
but exist only to support it. Very often, these "support classes" are located in the
middle or lower layers of a layered architecture, thus providing a common
support service to all application-level classes.
 Selected analysis mechanisms for the Course Registration System:
 o Persistency: A means to make an element persistent (that is, exist after the
application that created it ceases to exist).
o Distribution: A means to distribute an element across existing nodes of the
system.
o Security: A means to control access to an element.
o Legacy Interface: A means to access a legacy system with an existing interface.

Identify Key Abstractions:

 The purpose of this step is to "prime the pump" for analysis by identifying and defining
the key abstractions that the system must handle. These may have been initially
identified during business modeling and requirement activities. However, during those
activities, the focus was on the problem domain. During analysis and design, our focus
is more on the solution domain.
 What are key abstractions:
o A key abstraction is a concept, normally uncovered in Requirements, that the
system must be able to handle.
o Sources for key abstractions:
 Domain knowledge
 Requirements
 Glossary
 Domain Model, or the Business Model (if one exists)
 Defining key abstractions:
o Define analysis classes: The purpose of this step is not to identify a set of classes
that will survive throughout design, but to identify the key abstractions the
system must handle. Do not spend much time describing analysis classes in
detail at this initial stage, because there is a risk that you might identify classes
and relationships that are not actually needed by the use cases. Remember that
you will find more analysis classes and relationships when looking at the use
cases.
o Model analysis classes and relationships on class diagrams:
 Include a brief description of an analysis class
o Map analysis classes to necessary analysis mechanisms
 Key abstractions for the Course Registration System:
Create Use-Case Realizations:

 What is a Use-Case Realization?

 The value of Use-Case Realizations:
o Provides traceability from Analysis and Design back to Requirements
o The Architect creates the Use-Case Realization
o For each Use Case in the Use-Case Model, create a use-case realization in the
Design Model. The name for the use-case realization should be the same as the
associated use case, and a realize relationship should be the same as the
associated use case, and a realize relationship should be established from the
use-case realization to its associated use case.
Checkpoints (for designer):

 General:
o Is the package partitioning and layering done in a logically consistent way?
o Have the necessary analysis mechanisms been identified?
 Packages:
o Have we provided a comprehensive picture of the services of the packages in
upper-level layers?
 Classes:
o Have the key entity classes and their relationships been identified and accurately
modeled?
o Does the name of each class clearly reflect the role it plays?
o Are the key abstractions/classes and their relationships consistent with the
Business Model, Domain Model, Requirements, Glossary, etc.?

Mechanisms are actually one in

a spectrum of patterns we
find the well-structured software
systems. At the low end of the
food chain, we have idioms. An
idiom is an expression peculiar
to
a certain programming
language or application
culture,
representing a generally
accepted convention for use
of the
language.
A framework is collection of
classes that provide a set of
services for a particular
domain; a framework thus
exports a
number of individual classes
and mechanisms which c