Object Oriented System Design

(Unit-1)

by
Surendra Keshari
Assistant Professor
KIET Group of Institutions
1
 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.

2
 The reasons why object orientation works
oHigh level of abstraction.
oSeamless transition among different phases of software development.
oEncourage of good programming techniques.
oPromotion of reusability.

3
 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.
oTop-down approach: It supports abstraction of the function level.
oObjects oriented approach: It supports abstraction at the object level.

4
 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.

5
 Encouragement of good programming techniques
 Object oriented approach is not a magical one to promote perfect design (or) perfect code.
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.
 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
o Promote clearer designs.
o Makes implementation easier.
o Provide overall better communication.

6
 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 different and enhancements between the classes need to be
designed and coded. All the previous functionality remains and can be reused
without change.

7
 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 different and enhancements between the classes need to be
designed and coded. All the previous functionality remains and can be reused
without change.

8
Procedural and Object Oriented Programming

9
 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, COBOL, BASIC,
Pascal and C.

10
 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, Swift, Scala.

11
Differences between Procedural and 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 Object oriented programming

down approach. follows bottom 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 Object oriented programming provides data
any proper way for hiding data so it hiding so it is more secure.
is less secure.
In procedural programming, overloading Overloading is possible in object oriented
is not possible. programming.
In procedural programming, function is In object oriented programming, data is
more important than data. more important than function.
Procedural programming is based Object oriented programming is based
on unreal world. on real world.
Examples: C, FORTRAN, Pascal, Basic Examples: C++, Java, Python, C# 12
etc.
Object

13
 Object
 Objects are key to understanding object-oriented technology
 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 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.

14
 Real-world objects
 Look around, 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, 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.

15
 Software objects
 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:

16
 Characteristics of objects
 Objects are an abstraction – represent real world entities.
 Objects have state – have a value at a particular time.
 Objects have operations –associated set of operations called methods
that describe how to carry out operations.
 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.

17
Important points to know about OOP
 OOP treats data as a critical element.

 Emphasis is on data rather than procedure.

 Decomposition of the problem into simpler modules.

 Doesn’t allow data to freely flow in the entire system, i.e. localized control flow.

 Data is protected from external functions.

18
 Properties of Object Oriented
 Abstraction
 Encapsulation
 Inheritance
 Polymorphism
 Generosity

19
 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.

20
 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.

21
 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.

22
 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.

23
 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.

24
 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.

25
 Disadvantages of OOP
 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.

26
 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.

27
Modeling

28
 Importance of modeling
 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.
 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

29
 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.

30
 Principles of Modeling
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.

31
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.

32
 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.

33
 The best models are connected to reality
 A 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, 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.

34
 No single model is sufficient
 No single model is sufficient. Every nontrivial system is best approached
through a small set of ―nearly independent‖ models
 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.

35
 Object Oriented Modeling:

1. Algorithmic perspective
2. Object-oriented perspective

36
 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 the system grows, systems built with an algorithmic
focus turn out to be very hard to maintain.

37
 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 , state and behavior.

38
 Unified Modeling Language (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.

39
 Unified Modeling Language (UML)

The UML is a language for

 Visualizing
 Specifying
 Constructing
 Documenting

40
 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:
Specifying means building models that are precise, unambiguous, and complete.

41
 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
42
 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

43
 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.

44
 Unified Modeling Language (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.

45
 Unified Modeling Language (UML)
The UML is a language for
 Visualizing
 Specifying
 Constructing
 Documenting

46
Conceptual Model of UML

47
 Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building blocks:

 1. Things
 2. Relationships
 3. Diagrams

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

 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

49
 Structural things
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

50
 Class

 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.

51
 Interface
 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.

52
 Collaboration
 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

53
 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

54
 Active class

 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 .

55
 Component
 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

56
 Node
 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

57
Conceptual Model of UML

58
 Behavioral Things
 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

59
 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

60
 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

61
 Grouping Things
 Grouping Things are the organizational parts of UML models.
 These are the boxes into which a model can be decomposed.
 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

62
 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

63
Conceptual Model of UML

64
 Relationships in the UML

There are four kinds of relationships in the UML:

 1. Dependency
 2. Association
 3. Generalization
 4. Realization

65
 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

66
 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

67
 Generalization

 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.

68
 Realization

 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

69
Conceptual Model of UML

70
 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.
 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

71
 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.

72
 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
 Sequence diagrams and collaboration diagrams are isomorphic, meaning that
you can take one and transform it into the other

73
 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 state chart 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

74
 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

75
Conceptual Model of UML

76
Conceptual Model of UML

77
 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

78
 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

79
 Specification
 Specification 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

80
 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 adornments to the class's basic rectangular notation.

81
 Common Divisions
 Divisions In modeling object-oriented systems, the world often gets divided in
several ways.
1. Division of class and object: A class is an abstraction; an object is one concrete
manifestation of that abstraction.
In below 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.

82
2. Separation of interface and implementation: An interface declares a contract, and
an implementation represents one concrete realization of that contract, responsible for
faithfully carrying out the interface's complete semantics. In the UML, you can model
both interfaces and their 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.

83
3. 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 .

84
 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
1. Stereotypes
2. Tagged values
3. Constraints

85
 Extensibility Mechanisms
 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

86
Architecture

87
 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

88
 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

89
 Use Case view
 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.

90
 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.

91
 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.

92
 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

93
 Implementation View

 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.

94
 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.

95
Thank
You
96