Object Oriented System Design

(BCS-054)

Unit-1
Introduction: The meaning of Object Orientation, object identity, Encapsulation, information
hiding, polymorphism, generosity, importance of modelling, principles of modelling, object
oriented modeling , Introduction to UML, conceptual model of the UML, Architecture.
Introduction to Object Orientation:
Object oriented methods enable us to create sets of objects that work together synergistically to
produce software that better module their problem domains than similar systems produced by
traditional techniques. The system created using object oriented methods are easier to adapt
changing requirements, easier to maintain, more robust, promote greater design. The reasons
why object orientation works:
1. High level of abstraction.
2. Seamless transition among different phases of software development.
3. Encourage of good programming techniques.
4. Promotion of reusability.

1. High level of abstraction:

The object encapsulate both the data (attributes) and functions (methods), they work as a
higher level of abstraction. The development can proceed at the object level, this makes
designing, coding, testing, and maintaining the system much simpler.
Top-down approach: It supports abstraction of the function level.
Objects oriented approach: It supports abstraction at the object level.
2. Seamless transition among different phases of software development:
Traditional Approach:
The software development using this approach requires different styles and methodologies
for each step of the process. So moving from one phase to another requires more complex
transition.
Object-oriented approach:
We use the same language to talk about analysis, design, programming and Database design.
It returns the level of complexity and reboundary, which makes clearer and robust system
development.

2
 3. Encouragement of good programming techniques:
A class in an object-oriented system carefully delineates between its interface and the
implementation of that interface. The attributes and methods are encapsulated within a class (or)
held together tightly. The classes are grouped into subsystems but remain independent one class
has no impact on other classes. Object oriented approach is not a magical one to promote perfect
design (or) perfect code.
Raising the level of abstraction from function level to object level and focusing on the real-world
aspects of the system, the object oriented method tends to
• Promote clearer designs.
• Makes implementation easier.
• Provide overall better communication.
4. Promotion of Reusability:
Objects are reusable because they are modeled directly out of real world.
The classes are designed generically with reuse. The object orientation adds inheritance, which is
a powerful technique that allows classes to built from each other. The only differents and
enhancements between the classes need to be designed and coded. All the previous functionality
remains and can be reused without change.

3
 Procedural and Object Oriented Programming
Procedural Programming: Procedural Programming can be defined as a programming model
which is derived from structured programming, based upon the concept of calling procedure.
Procedures, also known as routines, subroutines or functions, simply consist of a series of
computational steps to be carried out. During a program’s execution, any given procedure might
be called at any point, including by other procedures or itself.
Languages used in Procedural Programming: FORTRAN, ALGOL, COBOL, BASIC, Pascal and
C.
Object Oriented Programming: Object oriented programming can be defined as a
programming model which is based upon the concept of objects. Objects contain data in the form
of attributes and code in the form of methods. In object oriented programming, computer
programs are designed using the concept of objects that interact with real world. Object oriented
programming languages are various but the most popular ones are class-based, meaning that
objects are instances of classes, which also determine their types.
Languages used in Object Oriented Programming: Java, C++, C#, Python, PHP, JavaScript,
Ruby, Perl, Objective-C, Dart, Swift, Scala.
Differences between Procedural and Object Oriented Programming:

Procedural Oriented Programming Object Oriented Programming

In procedural programming, program is In object oriented programming, program is

divided into small parts called functions. divided into small parts called objects.
Procedural programming follows top down Object oriented programming follows bottom
approach. up approach.
There is no access specifier in procedural Object oriented programming have access
programming. specifiers like private, public, protected etc.
Adding new data and function is not easy. Adding new data and function is easy.
Procedural programming does not have any Object oriented programming provides data
proper way for hiding data so it is less secure. hiding so it is more secure.
In procedural programming, overloading is not Overloading is possible in object oriented

SKK−OOS−KIET−IT Unit−1 (Academic Purpose Only) 4

4
possible. programming.
In procedural programming, function is more In object oriented programming, data is more
important than data. important than function.
Procedural programming is based on unreal Object oriented programming is based on real
world. world.
Examples: C, FORTRAN, Pascal, Basic etc. Examples: C++, Java, Python, C# etc.

Object:
Objects are composite data types. An object provides for the storage of multiple data values in a
single unit. Each value is assigned a name which may then be used to reference it. Each element
in an object is referred to as a property. Object properties can be seen as an unordered list of
name value pairs contained within the container object.
Object comes in two flavors. There are system defined objects, which are predefined and come
with the JavaScript parser or with the browser running the parser. And there are user defined
objects, which the programmer creates.
Objects are key to understanding object-oriented technology.
Look around right now and you'll find many examples of real-world objects: your dog, your
desk, your television set, your bicycle.
Real-world objects share two characteristics: They all have state and behavior. Dogs have state
(name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Bicycles also have
state (current gear, current pedal cadence, current speed) and behavior (changing gear, changing
pedal cadence, applying brakes). Identifying the state and behavior for real-world objects is a
great way to begin thinking in terms of object-oriented programming.

5
Software objects are conceptually similar to real-world objects: they too consist of state and
related behavior. An object stores its state in fields (variables in some programming languages)
and exposes its behavior through methods (functions in some programming languages). Methods
operate on an object's internal state and serve as the primary mechanism for object-to-object
communication. Hiding internal state and requiring all interaction to be performed through an
object's methods is known as data encapsulation— a fundamental principle of object-oriented
programming. Consider a bicycle, for example:

Object is an instance of a class. Class is an entity in which data and functions are
organized. Each object has a class which defines its data and behavior. When program is
executed, the objects interact by sending messages to one another. Object has some
characteristics explained below.
a) Objects are an abstraction – represent real world entities.
b) Objects have state – have a value at a particular time.
c) Objects have operations – associated set of operations called methods that describe
how to carry out operations.
d) Objects have messages – request an object to carry out one of its operations by
sending. it a message and messages are the means by which we exchange data between
objects.

6
 Properties of Object Oriented
Abstraction:
Abstraction refers to the act of representing essential features without including the
background details or explanations.

Real life example of Abstraction is ATM Machine; All are performing operations on the ATM
machine like cash withdrawal, money transfer, retrieve mini-statement…etc. but we can't know
internal details about ATM.
Encapsulation:
Wrapping up of data and functions into a single unit (class) is known as encapsulation. The
data is not accessible to the outside world and only those functions which are wrapped in
the class can access it.

7
Inheritance:
Inheritance is the process by which objects of one class acquire the properties of object of
another class. It supports the concept of hierarchical classification. In OOP, the concept of
inheritance provides the idea of reusability.

Polymorphism:
Polymorphism means ability to take more than one form. An operation may exhibit different
behaviors in different instances. The behavior depends upon the types of data used in
operation. Ex. Addition of two numbers, concatenation in case of string. The process of
making an operator to exhibit different behavior in difference instances is known as
operator overloading. Polymorphism is extensively used in implementing inheritance.

Generosity:
Generosity is a technique for defining software components that have more than one
interpretation depending on the data types of parameters. It allows the declaration of data
items without specifying their exact data type. Such unknown data types (generic data type)
are resolved at the time of their usage based on the data type of parameters during a function
call.

8
Some important points to know about OOP:
1. OOP treats data as a critical element.
2. Emphasis is on data rather than procedure.
3. Decomposition of the problem into simpler modules.
4. Doesn’t allow data to freely flow in the entire system, ie localized control flow.
5. Data is protected from external functions.
Advantages of OOPs –
• It models the real world very well.
• With OOP, programs are easy to understand and maintain.
• OOP offers code reusability. Already created classes can be reused without having to write
them again.
• OOP facilitates the quick development of programs where parallel development of classes
is possible.
• With OOP, programs are easier to test, manage and debug.
Disadvantages of OOPs –
• With OOP, classes sometimes tend be over-generalized.
• The relations among classes become superficial at times.
• The OOP design is tricky and requires appropriate knowledge. Also, one needs to do
proper planning and design for OOP programming.
• To program with OOP, the programmer needs proper skills such as that of design,
programming and thinking in terms of objects and classes etc.
Some other benefits of OOPs:
• Through inheritance, we can eliminate redundant code and extend the use of existing
classes.
• We can build programs from standard working modules that communicate with one

another.
• The principle of data hiding helps the programmer to build secure programs.
• It is possible to have multiple instances of an object to co-exist without any interference.
• The data – centered design approach enables us to capture more details of a model in
implementable form.
• Object oriented systems can be easily upgraded from small to large systems.
• Software complexity can be easily managed.

Importance of modeling:
9
Modeling is a proven and well-accepted engineering technique. We build architectural
models of houses and high rises to help their users visualize the final product. We may
even build mathematical models in order to analyze the effects of winds or earthquakes on our
buildings.
A model is a simplification of reality. A model provides the blueprints of a system.
Models may encompass detailed plans, as well as more general plans. A good model
includes those elements that have broad effect and omits those minor elements that are not
relevant to the given level of abstraction. Every system may be described from different
aspects using different models, and each model is therefore a semantically closed abstraction
of the system. A model may be structural, emphasizing the organization of the system, or it
may be behavioral, emphasizing the dynamics of the system.
We build models so that we can better understand the system we are developing.
There are several advantages of modeling:
• Models help us to visualize a system as it is or as we want it to be.
• Models permit us to specify the structure or behavior of a system.
• Models give us a template that guides us in constructing a system.
• Models document the decisions we have made.

Principles of Modeling:
There are four basic principles of model
1. The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through a small
set of nearly independent models.

10
 1. The choice of what models to create has a profound influence on how a problem is
attacked and how a solution is shaped.
If you build a system through the eyes of a database developer, you will likely focus on
entity-relationship models that push behavior into triggers and stored procedures. If you
build a system through the eyes of a structured analyst, you will likely end up with models
that are algorithmic-centric, with data flowing from process to process. If you build a
system through the eyes of an object-oriented developer, you'll end up with a system whose
architecture is centered around a sea of classes and the patterns of interaction that direct how
those classes work together.
2. Every model may be expressed at different levels of precision.
A quick and simple executable model of the user interface is exactly what you need; at other
times, you have to get down and dirty with the bits, such as when you are specifying cross-
system interfaces or wrestling with networking bottlenecks. In any case, the best kinds of
models are those that let you choose your degree of detail, depending on who is doing the
viewing and why they need to view it. An analyst or an end user will want to focus on
issues of what; a developer will want to focus on issues of how. Both of these stakeholders
will want to visualize a system at different levels of detail at different times.
3. The best models are connected to reality.
Achilles heel of structured analysis techniques is the fact that there is a basic disconnect
between its analysis model and the system's design model. Failing to bridge this chasm
causes the system as conceived and the system as built to diverge over time. In object-
oriented systems, it is possible to connect all the nearly independent views of a system into one
semantic whole.
4. No single model is sufficient. Every nontrivial system is best approached through a
small set of nearly independent models.
The operative phrase here is "nearly independent." In this context, it means having models
that can be built and studied separately but that are still interrelated. As in the case of a
building, you can study electrical plans in isolation, but you can also see their mapping to
the floor plan and perhaps even their interaction with the routing of pipes in the plumbing
plan.

In software, there are several ways to approach a model. The two most common ways are
11
1. Algorithmic perspective
2. Object-oriented perspective
1. Algorithmic perspective:
The traditional view of software development takes an algorithmic perspective. In this
approach, the main building block of all software is the procedure or function. This view
leads developers to focus on issues of control and the decomposition of larger algorithms
into smaller ones. There's nothing inherently evil about such a point of view except that it
tends to yield brittle systems. As requirements change (and they will) and the system grows
(and it will), systems built with an algorithmic focus turn out to be very hard to maintain.
2. Object-oriented perspective :
The contemporary view of software development takes an object-oriented perspective. In
this approach, the main building block of all software systems is the object or class. Simply
put, an object is a thing, generally drawn from the vocabulary of the problem space or the
solution space; a class is a description of a set of common objects. Every object has identity
(you can name it or otherwise distinguish it from other objects), state (there's generally some
data associated with it), and behavior (you can do things to the object, and it can do things to
other objects, as well).
The object-oriented approach to software development is decidedly a part of the
mainstream simply because it has proven to be of value in building systems in all sorts of
problem domains and encompassing all degrees of size and complexity.

12
 Introduction to UML:
• The Unified Modeling Language is a standard language for writing software blueprints.
The UML may be used to visualize, specify, construct, and document the artifacts of a
software-intensive system.
• The UML is appropriate for modeling systems ranging from enterprise information
systems to distributed Web-based applications and even to hard real time embedded
systems. It is a very expressive language, addressing all the views needed to develop and
then deploy such systems.
The UML is a language for
Ø Visualizing
Ø Specifying
Ø Constructing
Ø Documenting
Visualizing: The UML is more than just a bunch of graphical symbols. Rather, behind each
symbol in the UML notation is a well-defined semantics. In this manner, one developer can write
a model in the UML, and another developer, or even another tool, can interpret that model
unambiguously
Specifying: means building models that are precise, unambiguous, and complete.
Constructing: the UML is not a visual programming language, but its models can be directly
connected to a variety of programming languages
Documenting: a healthy software organization produces all sorts of artifacts in addition to raw
executable code. These artifacts include
1. Requirements
2. Architecture
3. Design
4. Source code
5. Project plans
6. Tests
7. Prototypes
8. Releases

13
Where Can the UML Be Used?
Ø Enterprise information systems
Ø Banking and financial services
Ø Telecommunications
Ø Transportation
Ø Defense/aerospace
Ø Retail
Ø Medical electronics
Ø Scientific
Ø Distributed Web-based services

The UML is not limited to modeling software. In fact, it is expressive enough to model
non software systems, such as workflow in the legal system, the structure and behavior of a
patient healthcare system, and the design of hardware.

14
 Conceptual Model of UML
To understand the UML, you need to form a conceptual model of the language, and this requires
learning three major elements: the UML's basic building blocks, the rules that dictate how those
building blocks may be put together, and some common mechanisms that apply throughout the
UML.

Conceptual Model of UML

Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams

Things are the abstractions that are first-class citizens in a model; relationships tie these things
together; diagrams group interesting collections of things.

15
Things in the UML
There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML. You use them to
write well-formed models.
Structural things are the nouns of UML models. These are the mostly static parts of a
model, representing elements that are either conceptual or physical. In all, there are seven kinds
of structural things.
1. Classes
2. Interfaces
3. Collaborations
4. Use cases
5. Active classes
6. Components
7. Nodes

Class is a description of a set of objects that share the same attributes, operations,
relationships, and semantics. A class implements one or more interfaces. Graphically, a class is
rendered as a rectangle, usually including its name, attributes, and operations.

16
 Interface is a collection of operations that specify a service of a class or component. An
interface therefore describes the externally visible behavior of that element. An interface might
represent the complete behavior of a class or component or only a part of that behavior. An
interface is rendered as a circle together with its name. An interface rarely stands alone. Rather,
it is typically attached to the class or component that realizes the interface.

Collaboration defines an interaction and is a society of roles and other elements that
work together to provide some cooperative behavior that's bigger than the sum of all the
elements. Therefore, collaborations have structural, as well as behavioral, dimensions. A given
class might participate in several collaborations.
Graphically, a collaboration is rendered as an ellipse with dashed lines, usually including only its
name

Use case
• Use case is a description of set of sequence of actions that a system performs that yields
an observable result of value to a particular actor
• Use case is used to structure the behavioral things in a model.
• A use case is realized by a collaboration. Graphically, a use case is rendered as an ellipse
with solid lines, usually including only its name

17
 Active class is just like a class except that its objects represent elements whose behavior
is concurrent with other elements. Graphically, an active class is rendered just like a class, but
with heavy lines, usually including its name, attributes, and operations

Component is a physical and replaceable part of a system that conforms to and provides
the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with
tabs

Node is a physical element that exists at run time and represents a computational
resource, generally having at least some memory and, often, processing capability. Graphically, a
node is rendered as a cube, usually including only its name

18
 Behavioral Things are the dynamic parts of UML models. These are the verbs of a
model, representing behavior over time and space. In all, there are two primary kinds of
behavioral things
1. Interaction
2. State machine
Interaction
Interaction is a behavior that comprises a set of messages exchanged among a set of objects
within a particular context to accomplish a specific purpose. An interaction involves a number of
other elements, including messages, action sequences and links. Graphically a message is
rendered as a directed line, almost always including the name of its operation.

State Machine
State machine is a behavior that specifies the sequences of states an object or an interaction goes
through during its lifetime in response to events, together with its responses to those events. State
machine involves a number of other elements, including states, transitions, events and activities.
Graphically, a state is rendered as a rounded rectangle, usually including its name and its sub
states.

19
1. are the organizational parts of UML models. These are the boxes into which a model can be
decomposed
2. There is one primary kind of grouping thing, namely, packages.

Package:-
• A package is a general-purpose mechanism for organizing elements into groups.
Structural things, behavioral things, and even other grouping things may be placed in a
package
• Graphically, a package is rendered as a tabbed folder, usually including only its name
and, sometimes, its contents

Annotational things:-
Annotational things are the explanatory parts of UML models. These are the comments
you may apply to describe about any element in a model.
A note is simply a symbol for rendering constraints and comments attached to an element
or a collection of elements. Graphically, a note is rendered as a rectangle with a dog-eared
corner, together with a textual or graphical comment

20
Relationships in the UML: There are four kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
Dependency:-
Dependency is a semantic relationship between two things in which a change to one thing may
affect the semantics of the other thing. Graphically a dependency is rendered as a dashed line,
possibly directed, and occasionally including a label.

Association
an association is a structural relationship among classes that describes a set of links, a link being
a connection among objects that are instances of the classes. Aggregation is a special kind of
association, representing a structural relationship between a whole and its parts. Graphically, an
association is rendered as a solid line, possibly directed, occasionally including a label, and often
containing other adornments, such as multiplicity and end names

Aggregation
a generalization is a specialization/generalization relationship in which the specialized element
(the child) builds on the specification of the generalized element (the parent). The child shares
the structure and the behavior of the parent. Graphically, a generalization relationship is rendered
as a solid line with a hollow arrowhead pointing to the parent,

Realization is a semantic relationship between classifiers, wherein one classifier specifies a

contract that another classifier guarantees to carry out. Graphically a realization relationship is
rendered as a cross between a generalization and a dependency relationship

21
Diagrams in the UML:
Diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships). In theory, a diagram may contain
any combination of things and relationships.
For this reason, the UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

Class diagram
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. Class diagrams that include active classes address the static process view of a
system.
Object diagram
Object diagrams represent static snapshots of instances of the things found in class
diagrams. These diagrams address the static design view or static process view of a system. An
object diagram shows a set of objects and their relationships
Use case diagram
A use case diagram shows a set of use cases and actors and their relationships. Use case
diagrams address the static use case view of a system. These diagrams are especially important in
organizing and modeling the behaviors of a system.
Interaction Diagrams
Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams.
Interaction diagrams address the dynamic view of a system
A sequence diagram is an interaction diagram that emphasizes the time-ordering of
messages
A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages

22
Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one
and transform it into the other
State chart diagram
A state chart diagram shows a state machine, consisting of states, transitions, events, and
activities. State chart diagrams address the dynamic view of a system. They are especially
important in modeling the behavior of an interface, class, or collaboration and emphasize the
event-ordered behavior of an object.
Activity diagram
An activity diagram is a special kind of a statechart diagram that shows the flow from
activity to activity within a system. Activity diagrams address the dynamic view of a system.
They are especially important in modeling the function of a system and emphasize the flow of
control among objects
Component diagram
A component diagram shows the organizations and dependencies among a set of
components. Component diagrams address the static implementation view of a system.They are
related to class diagrams in that a component typically maps to one or more classes, interfaces, or
collaborations
Deployment diagram
A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them. Deployment diagrams address the static deployment view of an
architecture

23
Rules of the UML:
The UML's building blocks can't simply be thrown together in a random fashion. Like
any language, the UML has a number of rules that specify what a well-formed model should
look like. A well-formed model is one that is semantically self-consistent and in harmony with
all its related models.
The UML has semantic rules for
1. Names What you can call things, relationships, and diagrams
2. Scope The context that gives specific meaning to a name
3. Visibility How those names can be seen and used by others
4. Integrity How things properly and consistently relate to one another
5. Execution What it means to run or simulate a dynamic model

Models built during the development of a software-intensive system tend to evolve and
may be viewed by many stakeholders in different ways and at different times. For this reason, it
is common for the development team to not only build models that are well-formed, but also to
build models that are
1. Elided Certain elements are hidden to simplify the view
2. Incomplete Certain elements may be missing
3. Inconsistent The integrity of the model is not guaranteed

Common Mechanisms in the UML

UML is made simpler by the presence of four common mechanisms that apply consistently
throughout the language.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms
Specification that provides a textual statement of the syntax and semantics of that
building block. The UML's specifications provide a semantic backplane that contains all the
parts of all the models of a system, each part related to one another in a consistent fashion
Adornments Most elements in the UML have a unique and direct graphical notation that
provides a visual representation of the most important aspects of the element. A class's
specification may include other details, such as whether it is abstract or the visibility of its
attributes and operations. Many of these details can be rendered as graphical or textual
24
adornments to the class's basic rectangular notation.

Common Divisions In modeling object-oriented systems, the world often gets divided in
several ways.
First, there is the division of class and object. A class is an abstraction; an object is one
concrete manifestation of that abstraction. In the UML, you can model classes as well as objects,
as shown in Figure. Graphically, the UML distinguishes an object by using the same symbol as
its class and then simply underlying the object's name.

Classes and Objects

In this figure, there is one class, named Customer, together with three objects: Jan (which
is marked explicitly as being a Customer object), :Customer (an anonymous Customer object),
and Elyse (which in its specification is marked as being a kind of Customer object, although it's
not shown explicitly here).

Almost every building block in the UML has this same kind of class/object dichotomy.
For example, you can have use cases and use case executions, components and component
instances, nodes and node instances, and so on.
Second, there is the separation of interface and implementation. An interface declares a
contract, and an implementation represents one concrete realization of that contract, responsible

25
for faithfully carrying out the interface's complete semantics. In the UML, you can model both
interfaces and their implementations, as shown in Figure.

Interfaces and Implementations

In this figure, there is one component named SpellingWizard.dll that provides

(implements) two interfaces, IUnknown and ISpelling. It also requires an interface, IDictionary,
that must be provided by another component.
Almost every building block in the UML has this same kind of interface/implementation
dichotomy. For example, you can have use cases and the collaborations that realize them, as well
as operations and the methods that implement them.
Third, there is the separation of type and role. The type declares the class of an entity,
such as an object, an attribute, or a parameter. A role describes the meaning of an entity within
its context, such as a class, component, or collaboration. Any entity that forms part of the
structure of another entity, such as an attribute, has both characteristics: It derives some of its
meaning from its inherent type and some of its meaning from its role within its context (Figure).
Part with role and type

26

26
 Extensibility Mechanisms The UML provides a standard language for writing software
blueprints, but it is not possible for one closed language to ever be sufficient to express all
possible nuances of all models across all domains across all time. For this reason, the UML is
opened-ended, making it possible for you to extend the language in controlled ways. The UML's
extensibility mechanisms include:
• Stereotypes
Stereotype extends the vocabulary of the UML, allowing you to create new kinds of
building blocks that are derived from existing ones but that are specific to your problem
• Tagged values
A tagged value extends the properties of a UML building block, allowing you to create
new information in that element's specification
• Constraints
A constraint extends the semantics of a UML building block, allowing you to add new
rules or modify existing ones

27

27
 Architecture

A system's architecture is perhaps the most important artifact that can be used to manage
these different viewpoints and so control the iterative and incremental development of a system
throughout its life cycle.
Architecture is the set of significant decisions about
1. The organization of a software system
2. The selection of the structural elements and their interfaces by which the system is composed
3. Their behavior, as specified in the collaborations among those elements
4. The composition of these structural and behavioral elements into progressively larger
subsystems
The architectural style that guides this organization: the static and dynamic elements and
their interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior, but also with usage,
functionality, performance, resilience, reuse, comprehensibility, economic and technology
constraints and trade-offs, and aesthetic concerns.

UML plays an important role in defining different perspectives of a system. These

perspectives are:
Design View
Implementation View
Process View
Deployment View
Use case View
And the centre is the Use Case view which connects all these four. A Use case represents
the functionality of the system. So the other perspectives are connected with use case.

28

28
Use case view
The use case view of a system encompasses the use cases that describe the behavior of the
system as seen by its end users, analysts, and testers.
With the UML, the static aspects of this view are captured in use case diagrams
The dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and
activity diagrams.

Design View
• The design view of a system encompasses the classes, interfaces, and collaborations that
form the vocabulary of the problem and its solution.
• This view primarily supports the functional requirements of the system, meaning the
services that the system should provide to its end users.

Process View
• The process view of a system encompasses the threads and processes that form the
system's concurrency and synchronization mechanisms.
• This view primarily addresses the performance, scalability, and throughput of the system

29
 The implementation view of a system encompasses the components and files that are used to
assemble and release the physical system.
This view primarily addresses the configuration management of the system's releases, made up
of somewhat independent components and files that can be assembled in various ways to
produce a running system.

Deployment View
The deployment view of a system encompasses the nodes that form the system's
hardware topology on which the system executes.

This view primarily addresses the distribution, delivery, and installation of the parts that
make up the physical system.

30

30