Complex Systems is a system

◦ whose parts give rise to the collective behaviors of the system,

◦ how the system interacts with its environment.
For our purpose complex systems (Booch):
◦ have many states, i.e. large "phase space",
◦ are hard to comprehend in total
◦ hard to predict
Examples:
◦ Computer, human body, weather
Attributes of a Complex System
1. Hierarchical: There exist a hierarchy of systems and interrelated subsystems ultimately
going down to a certain level of their own sub systems.
2. Different level of abstraction: The primitive components of a system are relatively
arbitrary and may be seen as a higher level of abstraction to another observer.
3. Decomposable: A system can be broken down into definite numbers of identifiable
parts, which are not completely independent. There are intracomponent and inter-
component interactions, which leads to the relative isolation of each component.
4. Reuse of common patterns: A complex system is made up of only a few kinds of
different sub systems in various combinations and arrangements. Many of them have
common patterns and are re-used to make a complex system.
5. Evolutionary: A complex system evolved over time from a number of simple working
systems. Making from scratch, a complex system can never be built successfully.

An example of Complex System: Structure of a Personal Computer

• A device of moderate complexity, which has been evolved from small working sub
systems like gate architecture, for instance.
• Composed of the same major elements – CPU, monitor, keyboard, secondary storage
• An element can be taken and decomposed further and can be studied separately.
• The collaborative activity of each major part (hierarchically arranged) causes a
computer system to function.
• The hierarchy of the computer system also represents different levels of abstraction –
each built upon another and in each level of abstraction, a collection of devices are
found to be collaborating one another to provide functions to higher layers.
Managing Complexity
• Organised complexity can be managed more easily than disorganised complexity. If
complex systems are in a standard (canonical) form i.e. includes five attributes and
class-object architecture, then the complexity is said to be organised.
 • There is yet another factor in complexity management – limited human capacity in
dealing with the complexity.
• There are three (3) ways to resolve the complexity – decomposition, abstraction and
hierarchy.

Role of Decomposition
• Divide and rule: Only a few parts need to be taken care of at a time.
• Ways of decomposing - Algorithmic and Object Oriented o Algorithmic Decomposition:
Process and steps are considered. Functional components are structurally designed
with their relationships. It mostly deal with “how” not “what”.
o Object Oriented Decomposition: Carries out the key abstraction in problem
domain by identifying objects from the vocabulary of the domain. It concerns
mainly with “what”; and all “how”s found in the vocabulary become operations of
related objects.

Role of Abstraction
• Multiple levels of abstraction exist. Also, different abstractions are possible from
several dimensions.
• When a higher level abstraction fails to succeed, we ignore inessential details and focus
on more generalised parts.

Role of Hierarchy
• By recognising the class and object hierarchies, the study of collaboration / interaction
in and among levels are made simpler.
• Discovery of common or dissimilar patterns of many objects are simplified once the
hierarchy is exposed and thus the identification of object behaviours too.

Q2. Software system are always complex. Justify with example.

“The complexity of software is an essential property, not an accidental one” –Frederick Brooks

Software Complexity
• Software might be referred to as simple or complex - depending upon their
functionality and behaviour. Generally, industrial-strength software are more complex
than those developed individually or by amateur developers.
• Time and space are considered to be general complexities. Additionally, maintaining
integrity of hundreds of thousands of records while allowing concurrent updates and
queries; or managing command and control of real-world entities like air traffic are also
examples of complex systems.

Software is inherently complex. Inherent complexity derives from four elements:

1. The complexity of the problem domain
2. The difficulty of managing the development process
 3. The flexibility possible through software
4. The problems of characterizing the behavior of discrete systems
1. The complexity of the Problem domain o Requirements – both functional
and non-functional (like usability, performance, cost, survivability,
reliability etc.) - give rise to complexity.
o Impedance mismatch between the users of a system and its developers in
understanding and expressing the problem domain also increases the level of
complexity
o Change in requirements during the development phase makes the system more
complicated.
2. The difficulty of managing the developing process o Engineering the illusion of simplicity is
challengingly difficult and tricky too. Systems with a millions of lines of codes are huge in
terms of space and even decomposing them might produce hundreds or thousands of
modules, which are hard for any developer or understand fully.
o Establishment of a team of software developers requires complex communication
and difficult coordination particularly if they are geographically dispersed. There
also is a challenge of team building as well as maintaining the unity and integrity of
the design.
3. The Flexibility possible through software o The highest possible flexibility of software
enables developers to express any level of abstraction, which turns out the software
development work to be labour intensive work because users expect higher level
abstraction be built on top of primitive building blocks.
4. The problems of characterizing the behaviour of discrete systems o In a continuous (analog)
system, a state is defined by a continuous function. In contrast, a discrete system has a
finite number of possible states.
o The present state of an application is depicted by a number of variables, their
current values and also by the current address and calling stack of each process.
o In a large discrete system, there is possibility of combinatorial explosions which
makes the finite number of possible states very large.
o An event external to a system has the potential to place the system in a new state
and thus making the mapping from state to state non deterministic – in worst case,
creating a corruption in the system too.
o There is no mathematical model nor do we have intellectual capacity to model
complete behaviours of large discrete system.

Explain the need of object oriented systems

Definition
In general, analysis emphasizes an investigation of the problem and requirements of the
domain, rather than a solution. Whereas, design emphasizes a conceptual solution that
fulfils the requirements, rather than its implementation.
 In OO analysis, emphasis is given on finding and describing the objects or concepts in the
problem domain. But in OO design, emphasis is given on defining software objects and
their collaboration for fulfilling the requirements.

OO Concept and Principles

• Objects exist in nature and thus OO technology reflects Real world scenario
• OO thinking is in abstraction level (should not be intoxicated with technological
implementation)
• OO leads to reuse of components/sub-systems (Component Based Development
model), which leads to a faster development as well as high quality programs.

Classes and Objects

• A Class is an OO concept that encapsulates the data and procedural abstractions
required to describe the content and behaviour of some real world entity.
• The data abstraction is implemented as attributes and the procedural abstraction as
operations or methods or services.
• Methods and objects are cohesive (i.e. methods can change some of the attributes of
objects) whereas classes tend be decoupled from other elements of the system (classes
can be communicated by other elements through methods only).

Attributes
• Description of classes and objects are attributes.
• Real life entities are described with words that indicate stable features (e.g. shape,
weight, colour, date or birth, name etc.) [Here, features = values of domain] Operations,
Methods, and Services
• Algorithms encapsulated in classes or objects, which process the data, are called
operations or methods or services, which are termed in conventional sense as
modules.
• Each operation represents one of the behaviours of a class or an object.
 • Objects are designed in such a way to be able to get a stimulus (often called message)
upon receiving which they start to behave through operations.

Messages
• Objects interact through messages.
• A message has i) destination, ii) operation and iii) parameters.
• Messages tie an object-oriented system together.

Encapsulation, Inheritance and Polymorphism

• Encapsulation helps achieve information hiding, in which the internal implementation
details of data and procedures are hidden from the outside world.
• Any object that sends a message to another object does not bother about the detail of
internal data structures of the object thus by reducing the propagation of side effects.
• Class hierarchy maintains the mechanism such that any change in data or operations
contained within a super class is immediately inherited by all subclasses. Multiple
inheritances could be achieved by restructuring or overriding the existing classes.
• Polymorphism allows a number of different operations to have the same name, which
in turn decouples objects from one another – making each object independent.
• Overloading concept is used for the purpose. For example the following design

case of graphtype:
If graphtype = linegraph then DrawLineGraph (data);
If graphtype = piegraph then DrawPieGraph (data);
If graphtype = xygraph then DrawXyGraph (data); If graphtype =
bargraph then DrawBarGraph (data); end case;

can be reduced to

graphtype draw
The OO Paradigm

• OO is evolutionary (incremental, spiral, concurrent development paradigms), not

revolutionary.
• Iterative process with resembling to Spiral model.
• It emphasizes the creation of classes
• The Unified Software Development Process is adopted – Rational Unified Process and
UML are the software industries’ best practices nowadays.

Compare object oriented and traditional software development life cycle.

The following table explains how the object-oriented approach differs from the traditional
structured approach −

Traditional Structured Approach Object Oriented Approach

It works with Top-down approach. It works with Bottom-up approach.

Program is divided into number of Program is organized by having

submodules or functions. number of classes and objects.

Function call is used. Message passing is used.

Software reuse is not possible. Reusability is possible.

 Structured design programming Object oriented design
usually left until end phases. programming done concurrently
with other phases.

Structured Design is more suitable It is suitable for in-house

for offshoring. development.

It shows clear transition from design Not so clear transition from design
to implementation. to implementation.

It is suitable for real time system, It is suitable for most business

embedded system and projects applications, game development
where objects are not the most projects, which are expected to
useful level of abstraction. customize or extended.

DFD & E-R diagram model the data. Class diagram, sequence diagram,
state chart diagram, and use cases
all contribute.

In this, projects can be managed In this approach, projects can be

easily due to clearly identifiable difficult to manage due to uncertain
phases. transitions between phase.

What is Object Oriented Design? Explain the characteristics of object oriented design.
Object Oriented Design is the concept that forces programmers to plan out their code in order to
have a better flowing program. The origins of object oriented design is debated, but the first
languages that supported it included Simula and SmallTalk. The term did not become popular until
Grady Booch wrote the first paper titled Object-Oriented Design, in 1982.

Object Oriented Design is defined as a programming language that has 5 conceptual tools to aid
the programmer. These programs are often more readable than non-object oriented programs,
and debugging becomes easier with locality.

The 5 Basic Concepts of Object Oriented Design are the implementation level features that are
built into the programming language. These features are often referred to by these common
names:
Encapsulation
A tight coupling or association of data structures with the methods or functions that act on the
data. This is called a class, or object (an object is often the implementation of a class).
Data Protection
The ability to protect some components of the object from external entities. This is realized by
language keywords to enable a variable to be declared as private or protected to the owning class.
Inheritance
The ability for a class to extend or override functionality of another class. The so called child class
has a whole section that is the parent class and then it has it's own set of functions and data.
Interface
A definition of functions or methods, and their signatures that are available for use to manipulate
a given instance of an object.
Polymorphism
The ability to define different functions or classes as having the same name but taking different
data types.
Programming Concepts
There are several concepts that were derived from the new languages once they became popular.
The new standards that came around pushed on three major things:

Re-usability
The ability to reuse code for multiple applications. If a programmer has already written a power
function, then it should be written that any program can make a call to that function and it should
work exactly the same.
Privacy
This is important for large programs and preventing loss of data.
Documentation
The commenting of a program in mark up that will not be converted to machine code. This mark
up can be as long as the programmer wants, and allows for comprehensive information to be
passed on to new programmers. This is important for both the re-usability and the maintainability
of programs.
Q06. OOA and OOD are parallel activities. Explain.
Object–Oriented Analysis (OOA) is the procedure of identifying software engineering
requirements and developing software specifications in terms of a software system’s object
model, which comprises of interacting objects.
Object–Oriented Design (OOD) involves implementation of the conceptual model produced during
object-oriented analysis. In OOD, concepts in the analysis model, which are
technology−independent are mapped onto implementing classes and constraints are identified.
Also, interfaces are designed which results in a model for the solution domain. In short, detailed
description of how the system is to be built on concrete technologies is what OOD states.
Basically, they are both strongly interrelated as we first need analysis before we design a new
model.
During Analysis, we try to determine which objects we need and how to organize them. We also
need to know what they contain and how they behave when they interact with other objects.
During design, we take the analyzed objects and add constraints to make them fit within the
software and hardware that we are developing for. Suffice it to say, we are trying to adjust the
object model to fit within the technology that we use.
Analysis is the investigation of real-world concepts (actual objects, physical and conceptual - as
well as tasks done on these) in and around what we are trying to make.
While design is the task of mapping their relations to one another on how we are going to make
the system know about objects. It states how the objects are related to one another, or linked to
each other.
We really cannot do the design before we do the analysis. This is not just limited to software
development but nearly everything. Analysis plays vital role in designing. The more amount of time
we give to analysis, better the design will be. Analysis will help us remind what the factors that
influence the design are and hence we can design in the best way. Hence OOA and OOD are parallel
activities. Both must run hand in hand and existence of only one factor impacts the other.
7. Explain Solid Principles for class identification.
There are five principles regarding SOLID principles for class identification:-
SOLID stands for
S= Single Responsibility.
O= Open- closed.
L= Liskov Substitution.
I= Interface Segregation
D=Dependency Inversion
1. Single Responsibility Principle:-
- The Single Responsibility Principle (SRP) states: A class should have only one
responsibility.
- Everything in the class should be related to that single purpose, i.e. be cohesive. It does
not mean that classes should only contain one method or property.
 - There can be a lot of members as long as they relate to the single responsibility. It may
be that when the one reason to change occurs, multiple members of the class may
need modification. It may also be that multiple classes will require updates.
2. Open-Closed Principle:-
- The Open-Closed Principle (OCP) states that classes should be open for extension but
closed for modification. “Open to extension” means that you should design your
classes so that new functionality can be added as new requirements are generated.
“Closed for modification” means that once you have developed a class you should
never modify it, except to correct bugs.

- These two parts of the principle appear to be contradictory. However, if you correctly
structure your classes and their dependencies, you can add functionality without
editing existing source code.
- Generally you achieve this by referring to abstractions for dependencies, such as
interfaces or abstract classes, rather than using concrete classes. Functionality can be
added by creating new classes that implement the interfaces.
- Applying OCP to your projects limits the need to change source code once it has been
written, tested and debugged. This reduces the risk of introducing new bugs to existing
code, leading to more robust software.
- There are two methods by which you can apply the open-closed principle. You can
apply this principle either through inheritance or through composition

3. Liskov Substitution Principle:-

- The Liskov Substitution Principle states: Derived classes must be substitutable for their
base classes.
- Another way to look at this definition is that abstraction (interface or abstract class)
should be enough for a client.
- The Liskov Substitution Principle (LSP) applies to inheritance hierarchies, specifying
that you should design your classes so that client dependencies can be substituted with
subclasses without the client knowing about the change.All subclasses must, therefore,
operate in the same manner as their base classes. The specific functionality of the
subclass may be different but must conform to the expected behavior of the base class.

4. Interface Segregation Principle:-

- The Interface Segregation Principle (ISP) states: Clients should not be forced to depend
upon the interfaces that they do not use.
- When we have non-cohesive interfaces, the ISP guides us to create multiple, smaller,
cohesive interfaces.
- When you apply ISP, classes and their dependencies communicate using tightly-
focused interfaces, minimizing dependencies on unused members and reducing
 coupling accordingly. Smaller interfaces are easier to implement, improving flexibility
and the possibility of reuse. As fewer classes share these interfaces, the number of
changes that are required in response to an interface modification is lowered, which
increases robustness.
5. Dependency Inversion Principle:-
- The principle is: Program to an interface, not to an implementation.
- The dependency inversion principle is a way to decouple software modules.
- This principle states that high-level modules should not depend on low-level modules.
Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
- The idea is that we isolate our class behind a boundary formed by the abstractions it
depends on. If all the details behind those abstractions change, then our class is still
safe. This helps keep coupling low and makes our design easier to change. DIP also
allows us to test things in isolation, details like database are plugins to our system.
By applying these 5 principles that make the SOLID acronym, we get to benefit from a reusable,
maintainable, scalable and easy testable codebase. These are 5 essential principles used by
professional software engineers all around the globe.

Q08 Define class and object. Explain different types of relationships exhibited by classes.

A class is a blueprint or template or set of instructions to build a specific type of object. It is a

technique used to bind data and its associated functions together. It represents the set of
properties or methods that are common to all objects of one type.
Classes may be arranged in a class hierarchy where one class (a super-class) is a generalization of
one or more other classes (sub-classes). A sub-class inherits the attributes and operations from its
super class and may add new methods or attributes of its own

An object is a self-contained component that contains properties and methods needed to make a
certain type of data useful. Objects are abstractions of real-world or system entities and manage
themselves. An object refers to a particular instance of a class, where the object can be a
combination of variables, functions, and data structures.

The different types of relationships exhibited by Classer are:

1. Inheritance
2. Aggregation
3. Dependency

1. Inheritance:
 It refers to a type of relationship wherein one associated class is a child of another by virtue
of assuming the same functionalities of the parent class. In other words, the child class is
a specific type of the parent class. To show inheritance in a UML diagram, a solid line from
the child class to the parent class is drawn using an unfilled arrowhead.

2. Aggregation
It refers to the formation of a particular class as a result of one class being aggregated or
built as a collection. For example, the class “library” is made up of one or more books,
among other materials. In aggregation, the contained classes are not strongly dependent
on the lifecycle of the container. In the same example, books will remain so even when the
library is dissolved. To show aggregation in a diagram, a line is drawn from the parent class
to the child class with a diamond shape near the parent class.

3. Dependency
A dependency indicates that an element on one end of the relationship, in some manner,
depends on the element on the other end of the relationship. This alerts the designer that
if one of these elements changes, there could be an impact to the other. a Cart class
depends on a Product class because the Cart class uses the Product class as a parameter
for an add operation so a change to the Product class might require a change to the Cart
class.
It is represented in classes diagram as dotted line with open arrow tip

Q9. What is UML? Explain significance of UML in system analysis and design.
Answer: The Unified Modeling Language (UML) is the primary modeling language used to analyze,
specify, and design software systems. Unified Modeling Language is a standardized modeling
language consisting of an integrated set of diagrams, developed to help system and software
developers for specifying, visualizing, constructing, and documenting the artifacts of software
systems, as well as for business modeling and other non-software systems. The UML represents a
collection of best engineering practices that have proven successful in the modeling of large and
complex systems. The UML is a very important part of developing object oriented software and
the software development process. The UML uses mostly graphical notations to express the design
of software projects. Using the UML helps project teams communicate, explore potential designs,
and validate the architectural design of the software. The UML toolset includes diagrams that
allow you to visualize the construction of an object-oriented system. Each design iteration takes a
successively more detailed look at the design of the system until the things and relationships in
the system are clearly and precisely defined in UML documents. UML is a powerful tool that can
greatly improve the quality of your systems analysis and design, and thereby help create higher-
quality information systems.

There are three basics steps where OO concepts are significant, applied and implemented. The
steps can be defined as below:

OO Analysis- OO Design OO implementation using OO languages. The significance of UML in

system analysis and design are as follows:

 To identify the objects of a system.

 To identify their relationships.
 To make a design which can be converted to executable using OO languages.

 During object oriented analysis the most important significance is to identify objects and
describing them in proper way. If these objects are identified efficiently then the next job
of design is easy. The objects should be identified with responsibilities. Responsibilities are
the functions performed by the object. Each and every object has some type of
responsibilities to be performed. When these responsibilities are collaborated the purpose
of the system is fulfilled.
 The second phase is object oriented design. During this phase emphasis is given upon the
requirements and their fulfillment. In this stage the objects are collaborated according to
their intended association. After the association is complete the design is also complete.
 The third phase is object oriented implementation. In this phase the design is
implemented using object oriented languages like Java, C++, etc.

What is a class diagram? Explain with example.

Class Diagrams
Class diagrams show the interactions between classes in the system. Classes can be
seen as the blueprint for objects. Joe's account, for example, is an object. An account is
a blueprint for Joe's checking account; an account is a class. Classes contain
information and behavior that acts on that information. The Account class contains the
customer's PIN and behavior to check the PIN. A class on a Class diagram is created for
each type of object in a Sequence or
Collaboration diagram.
The Class diagram shows the
Relationships between the classes that
implement the Withdraw Money use
case. This is done with four classes: Card
Reader, Account, ATM Screen, and Cash
Dispenser. Each class on a Class diagram
is represented by a rectangle divided into
three sections. The first section shows the
class name. The second section shows the
attributes the class contains. An attribute

is a piece of information that is associated Class diagram for the ATM system's Withdraw Money use case
with a class. For example, the Account class
contains three attributes: Account Number, PIN, and Balance. The last section contains the
operations of the class. An operation is some behavior that the class will provide. The
Account class contains four operations: Open, Withdraw Funds, Deduct Funds, and Verify
Funds.

The lines connecting classes show the communication relationships between the classes.
For instance, the Account class is connected with the ATM Screen class because the two
directly communicate with each other. The Card Reader is not connected to the Cash
Dispenser because the two do not communicate. Another point of interest is that some
attributes and operations have small padlocks to the left of them. The padlock indicates
a private attribute or operation. Private attributes and operations can only be accessed
from within the class that contains them. The Account Number, PIN, and Balance are all
private attributes of the Account class. In addition, the Deduct Funds and Verify Funds
operations are private to the Account class.

Developers use Class diagrams to actually develop the classes. Tools such as Rose
generate skeletal code for classes, then developers flesh out the details in the language
of their choice. Analysts use Class diagrams to show the details of the system. Architects
also look at Class diagrams to see the design of the system. If one class contains too much
functionality, an architect can see this in the Class diagram and split out the functionality
into multiple classes. Should no relationship exist between classes that communicate
with each other, an architect or developer can see this too. Class diagrams should be
created to show the classes that work together in each use case, and comprehensive
diagrams containing whole systems or subsystems can be created as well.

Draw class diagram and use case diagram.

Class diagram for the ATM system's Withdraw Money use case

This Use Case diagram shows the

interactions between the use cases
and actors of an ATM system. In this
example, the bank's customer
initiates a number of use cases:
Withdraw
Money, Deposit Funds,
Transfer Funds, Make
Payment, View Balance, and Change PIN. A few of the relationships are worthy of
further mention. The bank officer can Use Case diagram for an Automated Teller Machine (ATM) system
also initiate the Change PIN use case.
The Make Payment use case shows an arrow going to the credit system. External
systems may be actors and, in this case, the credit system is shown as an actor
because it is external to the ATM system. The arrow going from a use case to an actor
illustrates that the use case produces some information that an actor uses. In this
case, the Make Payment use case provides credit card payment information to the
credit system.
 Much information can be gleaned from viewing Use Case diagrams. This one diagram
shows the overall functionality of the system. Users, project managers, analysts,
developers, quality assurance engineers, and anyone else interested in the system as a
whole can view these diagrams and understand what the system is supposed to
accomplish.
Explain sequence diagram with example.
Sequence Diagrams
Sequence diagrams are used to show the flow of functionality through a use case. For
example, the Withdraw Money use case has several possible sequences, such as
withdrawing money, attempting to withdraw without available funds, attempting to
withdraw with the wrong PIN, and several others. The normal scenario of withdrawing
$20 (without any problems such as entering the wrong PIN or insufficient funds in the
account) is shown here.

This Sequence diagram shows the flow

of processing through the Withdraw
Money use case. Any actors involved
are shown at the top of the diagram;
the customer actor is shown in the
above example. The objects that the
system needs in order to perform the
Withdraw Money use case are also
shown at the top of the diagram. Each
arrow represents a message passed
between actor and object or object
and object to perform the needed
functionality.
One other note about Sequence
diagrams—they display objects, not
Sequence diagram for Joe withdrawing $20
classes. Classes represent types of objects,
they are specific; instead of just customer, the Sequence diagram shows Joe.
The use case starts with the customer inserting his card into the card reader, an object
indicated by the rectangle at the top of the diagram. Then, the card reader reads the card
number, opens Joe's account object, and initializes the ATM screen. The screen prompts
Joe for his PIN. He enters 1234. The screen verifies the PIN with the account object and
they match. The screen presents Joe with his options, and he chooses withdraw. The
screen then prompts Joe for the amount to withdraw. He chooses $20. Then, the screen
withdraws the funds from the account. This initiates a series of processes that the account
object performs. First, Joe's account verifies that the account contains at least $20. Then,
it deducts the funds from the account. Next, it instructs the cash dispenser to provide $20
 in cash. Joe's account also instructs the dispenser to provide a receipt. Lastly, it instructs
the card reader to eject the card.
This Sequence diagram illustrated the entire flow of processing for the Withdraw Money
use case by showing a specific example of Joe withdrawing $20 from his account. Users
can look at these diagrams to see the specifics of their business processing. Analysts see
the flow of processing in the Sequence diagrams. Developers see objects that need to be
developed and operations for those objects. Quality assurance engineers can see the
details of the process and develop test cases based on the processing. Sequence
diagrams are therefore useful for all stakeholders in the project.

What is domain analysis? Explain the stages of domain analysis.

The process of identifying, collecting, organizing, and representing the relevant information in a
domain, based upon the study of existing systems and their development histories, knowledge
captured from domain experts, underlying theory, and emerging technology within a domain.
Domain analysis is an activity occurring prior to system analysis. It aims to identify features
common to a domain of applications, selecting and abstracting the objects and operations that
characterize those features. Generally speaking, domain analysis should support extraction,
organization, analysis and abstraction, understanding, representation and modeling of reusable
information and assets from the software process.
Domain Analysis Activities
o Defining a glossary of terms.
o Documenting domain assumptions.
o Identifying domain stakeholders.
o Identifying problems within domain scope.
o Identifying legacy artifacts.
o Identifying commonalities and variabilities.

The general domain analysis model can be structured into four main phases, each phase
constituted by different activities:

1. Domain Characterization and project planning: the first step of every domain analysis
method is a preparation activity, which aims to collect the minimum information
concerning the problem that allows to decide if it is worth to deal with it and try to solve
it, or if it is not feasible to go on with the process. The main activities that have to be
carried out during this phase are:
a. Business Analysis;
b. Feasibility Analysis;
c. Domain Description;
d. Project planning and resource allocation.
 2. Data Analysis: the information necessary to the analysis are collected and organized,
then the analysis exploits domain commonalties and variations. The main activities
prescribed are:
a. Data Organization
b. Data Exploitation
3. Domain Modeling: the purpose of the modeling phase is to complete the previous
analysis step building suitable domain models of the domain, specifically:
a. Modeling commonalties aspects in the domain;
b. Refining domain models encapsulating variations possibilities;
c. Defining frameworks and general architecture for the domain;
d. Describing the rationale beneath domain models and tracing technical issue and
relative decisions made in the analysis and modeling process.

This phase can be considered the core activity aiming to produce reusable assets, such as
components, framework and architectures. The difference between domain modeling
and system modeling lies in the target chosen: for system modeling it is the specific
software system that has to be built, while for domain analysis it is a class of similar
systems in a specific application domain.

4. Evaluation: its purpose is to verify the results of each step of the domain analysis process,
identifying possible errors done in building the model, and to validate the results against
requirements and user expectations.

Explain class based modeling in domain analysis.

Class-Based Modeling

Class-based modeling identifies classes, attributes and relationships that the system will use. In
the airline application example, the traveler/user and the boarding pass represent classes. The
traveler's first and last name, and travel document type represent attributes, characteristics that
describe the traveler class. The relationship between traveler and boarding pass classes is that the
traveler must enter these details into the application in order to get the boarding pass, and that
the boarding pass contains this information along with other details like the flight departure gate,
seat number etc.
Class based modeling represents the object. The system manipulates the operations. The elements
of the class based model consist of classes and object, attributes, operations, class – responsibility
- collaborator (CRS) models.
The generic process described begins with guidelines for identifying potential analysis classes,
suggestions for defining attributes and operations for those classes, and a discussion of the Class-
Responsibility-Collaborator (CRC) model. The CRC card is used as the basis for developing a
network of objects that comprise the object-relationship model.
Explain scenario based modeling in domain analysis.
Ans: Scenario is a textual description of how a system behaves under a specific set of
circumstances. It also provides a basis for developing test cases and acceptance-level test plan.
Although the success of a computer-based system or product measured in many ways, user
satisfaction resides at the top of the list. If you understand how end user want to interact with a
system, your software team will be better able to properly characteristics requirements and build
meaningful analysis and design models. Hence requirement modeling with UML begins with the
creation of scenarios in the form of use case, activity diagram.

Scenario-based modeling

Use case
Activity diagrams

Use-case diagrams:
A use-case diagram is usually simple diagram which only summarize some of the relationship
between use-case, actor and systems. It does not show the detail of the use-case.
Scenario based modeling.
1. Creating a preliminary use case.
2. Refining a preliminary use case.
3. Writing a formal use case.

It is effective to use the first person "I" to describe how the actor interacts with the software
format of the text part of a use case.

Use-case title:
Actor:
Description:
Example: use-case diagram.
Activity Diagrams:
An activity diagram is essentially a flowchart that shows activities performed by a system. Or it
shows the graphical representation of the flow of interaction within a specific scenario.
Uses flowchart-like symbols

◦ Rounded rectangle - represent a specific system function/action

◦ Arrow - represents the flow of control from one function/action to another

◦ Diamond - represents a branching decision

◦ Solid bar – represents the fork and join of parallel activities

Example: Activity diagram.

Define an agent. Explain the role of an agent in improving performance of a software system.
An agent is an autonomous computer program that works in order to achieve goals in a dynamic
environment on behalf of an individual or computational entity over an extended period of time
without continuous supervision, exhibiting a degree of flexibility in transforming goals into action
tasks. In other words, A software agent is a piece of software that functions as an agent for
another piece of software working autonomously and continuously in a particularly significant
environment.
A software agent has the following characteristics:
- Reactive - Self-learning
- Deliberative - Communicative
- Goal driven - Collaborative
- Adaptive - Competitive
- Autonomous
Categories of software agent
- Biological Agents
- Robotics
- Computational Agents
o Software Agents
 Task Specific Agents
 Entertainment Agents
 Viruses
o Artificial Life Agents

Roles of an Agent to improve the Performance of Software Systems :

- Helps to conceptualize a software system as a society to solve complex computational

issues.
- An agent view provides a rigid form of modularity.
- An agent provides the ability to improve the performance of the system over time while
interacting with the environment in which they are embedded.
- Provides the ability to behave socially, i.e. interacting with other agents, exchange of
information, receives instructions and provides responses to help fulfill the goals.
- Agents provide the functionality to perform autonomously without users by monitoring
events and changes in the environment.
- A single software agent can operate single or multiple robots located in same or different
locations including the controlling interactions.
- Software agents are evolutionary beyond the constraints of object and programs.
- Software agents provide opportunities for parallelism and inter program collaboration in
a large scale to do it in a robust, flexible manner.

Explain the properties of an agent

Compare OOP and AOP:
Features OOP AOP
Definition Programming technology used to Programming technology used to
build the system which can build the system which can only
observe & act to changes in imitate the real world and cannot
environment in real world observe environment & act on its
own
Basic Unit of Objects, which are abstractions of Agents , which are abstractions of
Programming entities in real world Intelligent beings
Inter- Objects communicate using Agents communicate using Agent
communication methods Communication Language
Parameters Not constrained Constrained to beliefs,
defining state of commitments, choices,
Basic Unit capabilities.....contained by agents
Message Types Can produce any message defined Can produce limited messages viz.
by method Inform, request, offer, promise,
decline...based on mental state of
agents
Programming Class based Generic Role based
Computation By message passing & response By message passing & response
Process methods methods
Behaviour Exhibits flexible behaviours with Does not exhibit such behaviours
reactive, proactive, social abilities
Autonomous Capable of using rationale to Can only perform actions defined by
Action perform autonomous action and methods & is not autonomous and
has control of its own has no own control
Inheritance Supported Not Supported
Reusability Possible Not possible
Modular Supported Not supported
Architecture
Encapsulation & Supported Not supported
Data abstraction
Constraints on No constraints Constraints of honesty,
Methods consistency....
Suitable for Centralised organisational systems Complex Distributed Systems that
need to perform autonomous
actions
Q21. Explain agent representation in a class diagram with example.
Class diagram can be used to represent a static view of agent. Agent share some common
characteristics as shown in the figure below:
<<agent>> agent-name
Role
role 1, role 2, …, role n
role dynamic 1, role dynamic 2, …, role dynamic n
Organization
organization 1, organization 2, …, organization n
org dynamic 1, org dynamic 2, …, org dynamic n

As in class diagram, the top part represents identifier which identifies each agent in multi-agent
system. Next is role which defines the behavior of an agent into the society (e.g. Seller/buyer).
Organization defines the relationships between the roles. Beside these agent composes of
capability which specifies what an agent is able to do and under what conditions. Service which
describes an activity that an agent can perform and is provided to other agent.
Capability can be further broken down into following parts:
Input: What the agent must receive in input to achieve it task
Output: What the capability generates as a result of the work
Input constraints: Constraints that are expected to hold in the situation before the action
specified by the capability can be performed.
Output constraints: Constraints that are expected to hold in the situation after the action
specified by the capability has been preformed
Input-output constraints: Constraints that must hold across input and output situations
Description: A description in natural language of the capability

Q. 22. Compare the external and Internal quality of software.

Answer: It has been broadly accepted that quality is an abstract concept and cannot be easily
understood as a single entity in order to specify measurable elements clearly and directly. Thus, it
has been broken down into two components and their characteristics.
External Quality
External quality of software measures how the system meets the requirements of customer.
Internal Quality
Internal quality means all the properties of the software as seen by the developers that are
desirable in order to facilitate the process of creating a good product. It's the implementation,
which the customer never directly sees, and often does not want to spend time or money on.
Internal Quality of Software
Maintainability
Software should be maintainable. If some area
of software get defect, working of other ports
should not be distributed too much. It should
have good fault tolerance.
Flexibility
allows required modifications at the
appropriate locations to be made without
undesirable side effects
Portability
A software system can be said to be portable if
the effort required for porting it proves
significantly less than the effort necessary for a
new implementation.
Reusability
All or part of the software should be reusable in
other development too.
Testability:
It is the degree to which a software artifact
supports testing in a given test context
Understandability
Source code should be understandable to the
developers because it may influence the cost,
reusability and maintainability of the software.
Readability
Non-understandable software has poor
consistency and good design makes a software
understandable.
Concision :
Source code should not be suffered from
duplication
External Quality of Software
Correctness
Correctness is the degree to which software
performs its specified function.
Usability
- It should be easy and comfort to
operate or use
Efficiency
It is an ability of a software system to fulfill its
purpose with the best possible utilization of
all necessary resources like time, storage,
transmission channels, and peripherals.
Reliability
software should be able to maintain its
performance level under given conditions.
Integrity
Unauthorized access to the components of
software should be controlled.
Adaptability
Functions should be normal in any
environment
Accuracy
Output should be errorless.
Robustness:
Any exception raised during execution in
initial state should be caught by some
exception handler
<<agent>> sum <<capability>> addition
Role
Input
addition, subtraction
x,y:Integer
rd 1
Organization Output
calculator s:Integer
Protocol Description
enter-society, exit-society This capability makes the sum of two
compute integers and returns an integer

<<capability>> subtraction
<<service>> computation
Input
Description x,y:Integer
This service makes an addition when
Output
requested by the request addition
d:Integer
protocol and makes a subtraction when
requested by the request-subtraction Input Constraint
protocol x>=0, y>=0
Type Input-Output Constraint
computation x-y >=0
Description
Protocol
This capability makes the difference
request-addition
of two integers and returns an
request-subtraction
integer

Agent Communication Language

FIPA ACL
 Ontology
computation ontology
Content Language
FIPA SL

Fig. Example of Agent Representation of Sum in class diagram

Q23 What is a software metric? Explain with example
A software metric is a standard of measure of a degree to which a software system or process
possess some property. It is an attribute of a software system or process that can be expressed
numerically and measured. Software metrics is applied in schedule and budget planning, cost
estimation, quality assurance and testing, software debugging, software performance
optimization and optimal personnel task assignments. These metrics fall into one of two
categories: Process metrics and Product metrics.
Process metric are attributes of the process such as the time taken to complete a task. Process
metrics, sometimes called project metrics assist the management team in assessing progress with
respect to the object-oriented development process being used.
Examples: No of person hours expended, amount of work accomplished, number of project dollars
spend
Product metric are attributes of the software itself such as size or complexity. Product metric
sometimes called design metrics help the development team assess the artifacts of their analysis
and design efforts.

Chidamber and Kemerer suggest a number of language-independent design metrics

that are directly applicable to object-oriented systems
 Weighted methods per class (WMC)
 Depth of inheritance tree (DIT)
 Number of children (NOC)
 Coupling between object classes (CBO)
 Response for a class (RFC)
 Lack of cohesion in methods (LCOM)
Explain metrics for object oriented systems.
Object oriented design is becoming more popular in software development environment
and object oriented design metrics is an essential part of software environment. The
metrics for object oriented design focus on measurements that are applied to the class
and design characteristics. These measurements permit designers to access the software
early in process, making changes that will reduce complexity and improve the continuing
capability of the design. Object oriented metrics are used to measure properties of object
oriented designs. Metrics are a means for attaining more accurate estimations of project
milestones, and developing a software system that contains minimal faults. The following
characteristics require that special OO metrics be developed:
 Encapsulation — Concentrate on classes rather than functions
 Information hiding — An information hiding metric will provide an indication of
quality
 Inheritance — A pivotal indication of complexity
 Abstraction — Metrics need to measure a class at different levels of abstraction
and from different viewpoints
 OO Project Metrics
Number of Scenario Scripts (Use Cases):
 Number of use-cases is directly proportional the number of classes needed to
meet requirements
 A strong indicator of program size
Number of Key Classes (Class Diagram):
 A key class focuses directly on the problem domain
 NOT likely to be implemented via reuse
 Typically 20-40% of all classes are key, the rest support infrastructure (e.g. GUI,
communications, databases)
Number of Subsystems (Package Diagram):
 Provides insight into resource allocation, scheduling for parallel development and
overall integration effort
 OO Analysis and Design Metrics
Related to Analysis and Design Principles
Complexity:
 Weighted Methods per Class (WMC): Assume that n methods with cyclomatic
complexity are defined for a class C:

WMC   ci

 Depth of the Inheritance Tree (DIT): The maximum length from a leaf to the root
of the tree. Large DIT leads to greater design complexity but promotes reuse
  Number of Children (NOC): Total number of children for each class. Large NOC
may dilute abstraction and increase testing
OO Metrics
 Coupling:
 Coupling between Object Classes (COB): Total number of collaborations listed for
each class in CRC cards. Keep COB low because high values complicate
modification and testing
 Response For a Class (RFC): Set of methods potentially executed in response to a
message received by a class. High RFC implies test and design complexity
 Cohesion:
 Lack of Cohesion in Methods (LCOM): Number of methods in a class that access
one or more of the same attributes. High LCOM means tightly coupled methods
 Inheritance:
AIF- Attribute Inheritance Factor:
– Ratio of the sum of inherited attributes in all classes of the system to the total number
of attributes for all classes.

TC= total number of classes , Ad (Ci) = number of attribute declared in a class, Ai (Ci) =
number of attribute inherited in a class
MIF- Method Inheritance Factor:
– Ratio of the sum of inherited methods in all classes of the system to the total number
of methods for all classes.

TC= total number of classes, Md(Ci)= the number of methods declared in a class, Mi(Ci)=
the number of methods inherited in a class

 Use-Case Oriented Metrics

 Counting actors
Actor weighting factors
◦ Simple actor: represents another
system with a defined interface.
◦ Average actor: another system that
interacts through a text based
interface through a protocol such as
TCP/IP.
◦ Complex actor: person interacting
through a GUI interface.
The actors weight can be calculated by adding these values together.

Counting use cases

Transaction-based weighting factors
The number of each use case type is
counted in the software and then each
number is multiplied by a weighting factor
as shown in table above.

Q. 26 Explain the role of standard methodology in developing a quality software.

The ultimate objective of the quality software is to produce good quality, maintainable
software within reasonable time frame and at an affordable cost. This is achievable only if
we have matured processes to produce it. For a mature process, it should be possible to
determine in advance how much time and effort would be required to produce the final
product.
Developing a product without the guidance of a standard methodology often leads to
systems that are delivered late, over budget, and in many cases, that fail to meet customer
or end-user expectations. It could even lead to a complete project failure.
Software development organizations follow some method when developing a software
product. This methodology refers to the framework that is used to structure, plan, and
control the process of developing an information system. A wide variety of such
frameworks have evolved over the years, each with its own recognized strengths and
weaknesses.
Common methodologies include
  Waterfall,
 Prototyping,
 Iterative and incremental development,
 Spiral development,
 Agile development model
Often, several models are combined into some sort of hybrid methodology.
These methods generally promote a disciplined software development process that
encourages frequent inspection and adaptation. One software development methodology
is not necessarily suitable for use by all projects. Each of the available methodologies is
best suited to specific kinds of projects, based on various technical, organizational needs.
The key to success is first to start using standard methodology. We need to find what
works for us and stick to it. More importantly, as we move through the process, need to
be sure to adjust the methodology to better suit as per particular scenario and needs.
Q27 Define testing. Explain test case with an example.
Running a program with an intention of finding errors is called testing. A good testing
exposes as many errors as possible. A guidelines is defined to perform testing which
includes
 Selecting appropriate testing strategies
 Developing test case
 Executing test plan
While selecting testing strategies, we have following testing strategies
 Black box testing
 White box testing
 Top down testing
 Bottom up testig
Test case with example:
Set of Conditions under which an expert will determine whether an application, software
system or one of its feature is working as it was originally established for it to do.

Test Case: 2.2 Test Case name: change PIN

System: ATM Subsystem: PIN

Designed by: ABC Design date: 7/3/2019

Executed by: Execution Date:

Short Description: test ATM change PIN service

 Pre-condition

The user has a valid ATM card. The user has accessed the ATM by placing his ATM card in the
machine

The user pin is 1234

The system display main menu

Step Action Expected System PASS/FAIL Comment

1 Click change PIN The system displays message
button asking the user to enter new pin
2 Enter 5555 The system displays a message
asking the user to confirm(re-
enter the pin)
3 Reenter 5555 The system displays a message of
successful operation. The system
ask the user if he wants to perform
other operation
4 Click YES button The system displays main menue
5 Check Post
Condition1

Post Condition

1. The new pin 5555 is saved in the database

What is prototyping? Explain types of prototypes.

Prototype is a working model of software with some limited functionality. The prototype does
not always hold the exact logic used in the actual software application and is an extra effort to be
considered under effort estimation.

Prototyping is used to allow the users evaluate developer proposals and try them out before
implementation. It also helps understand the requirements which are user specific and may not
have been considered by the developer during product design.

Software Prototyping - Types

There are different types of software prototypes used in the industry. Following are the major
software prototyping types used widely −
Throwaway/Rapid Prototyping
Throwaway prototyping is also called as rapid or close ended prototyping. This type of
prototyping uses very little efforts with minimum requirement analysis to build a prototype. Once
the actual requirements are understood, the prototype is discarded and the actual system is
developed with a much clear understanding of user requirements.

Evolutionary Prototyping
Evolutionary prototyping also called as breadboard prototyping is based on building actual
functional prototypes with minimal functionality in the beginning. The prototype developed
forms the heart of the future prototypes on top of which the entire system is built. By using
evolutionary prototyping, the well-understood requirements are included in the prototype and
the requirements are added as and when they are understood.

Incremental Prototyping
Incremental prototyping refers to building multiple functional prototypes of the various sub-
systems and then integrating all the available prototypes to form a complete system.

Extreme Prototyping
Extreme prototyping is used in the web development domain. It consists of three sequential
phases. First, a basic prototype with all the existing pages is presented in the HTML format. Then
the data processing is simulated using a prototype services layer. Finally, the services are
implemented and integrated to the final prototype. This process is called Extreme Prototyping
used to draw attention to the second phase of the process, where a fully functional UI is
developed with very little regard to the actual services.

Compare evolutionary and throw-away prototype.

Evolutionary Prototype vs Throwaway Prototype

Evolutionary Prototype Throwaway Prototype

Definition A robust prototype that is A cheap, fast prototype can be

constantly refined. quickly discarded.

 Associated With Refined products Early stage design

Future concepts Minimum viable product

State of the

artdemonstrations

Evolutionary Prototyping Model

Advantages of Evolutionary Prototyping

 It’s useful for exploratory programming, such as Artificial Intelligence applications, where it is
difficult to frame specifications.
 If big problems are anticipated, developers can stop development after several iterations.
 This model is very suitable for research projects. For example, in order to develop software for
automatic speech recognition, it is possible to take a small vocabulary and develop a system.
After successful, you can gradually increase your vocabulary. This approach is superior to starting
the development of an unlimited vocabulary speech recognition system directly (I recognize it is
very difficult in two years).
 Disadvantages of Evolutionary Development Model

 As the project is open-ended, no time frame is able to be set.

 It is difficult to monitor the project.
 The visibility is low compared to the waterfall model.

Throw-away Prototyping Model

Advantages of Throw Away Prototyping

 Save time and money

 Promote consistency of user interface design
 Enable early customer engagement
 Show concrete ways to show and believe in management to management. Instead of telling the
administrator
 Marketers and planners guarantee that customer needs are met.

Disadvantages of Rapid Prototyping

 User confusion for prototypes and completed systems

 Excessive development time of the prototype
 Normally it does not generate reusable code
 The development process slows down when placed under formal configuration control
 There is no clear stop point
Q30. Compare validation and verification. Explain different strategies for software testing.

Verification Validation

Validation is a dynamic mechanism of

Verification is a static practice of verifying
validating and testing the actual
documents, design, code and program.
product.

It always involves executing the

It does not involve executing the code.
code.

It is human based checking of documents It is computer based execution of

and files. program.

Validation uses methods like black box

Verification uses methods like inspections,
(functional) testing, gray box testing,
reviews, walkthroughs, and Desk-
and white box (structural) testing
checking etc.
etc.

Validation is to check whether

Verification is to check whether the
software meets the customer
software conforms to specifications.
expectations and requirements.

It can catch errors that validation cannot It can catch errors that verification
catch. It is low level exercise. cannot catch. It is High Level Exercise.

Target is requirements specification,

Target is actual product-a unit, a
application and software architecture,
module, a bent of integrated
high level, complete design, and
modules, and effective final product.
database design etc.

Verification is done by QA team to ensure

Validation is carried out with the
that the software is as per the
involvement of testing team.
specifications in the SRS document.

It generally comes first-done before It generally follows after

validation. verification.
Different strategies for software testing are:
1. Analytic testing strategy: This uses formal and informal techniques to access and prioritize
risks that arise during software testing. It takes a complete overview of requirements,
design, and implementation of objects to determine the motive of testing. In addition, it
gathers complete information about the software, targets to be achieved, and the data
required for testing the software.

2. Model-based testing strategy: This strategy tests the functionality of the software according
to the real world scenario (like software functioning in an organization). It recognizes the
domain of data and selects suitable test cases according to the probability of errors in that
domain.

3. Methodical testing strategy: It tests the functions and status of software according to the
checklist, which is based on user requirements. This strategy is also used to test the
functionality, reliability, usability, and performance of the software.

4. Process-oriented testing strategy: It tests the software according to already existing

standards such as the IEEE standards. In addition, it checks the functionality of the software
by using automated testing tools.

5. Dynamic testing strategy: This tests the software after having a collective decision of the
testing team. Along with testing, this strategy provides information about the software
such as test cases used for testing the errors present in it.

6. Philosophical testing strategy: It tests the software assuming that any component of the
software can stop functioning anytime. It takes help from software developers, users and
systems analysts to test the software.