OOAD – Module 1

Introduction to Systems Concepts: Definition. Characteristics

of a System: Organization, Interaction, Interdependence,
Integration. Elements of a System: Inputs and Outputs,
Processor(s), Control, Feedback, Environment. Types of
Systems: Physical/Abstract Systems, Open/Closed Systems,
Man-made Information Systems. System Modelling: The
importance of Modelling, Principles of Modelling, Object-
Oriented Modelling , Introduction to UML. Best Practices of
Software Engineering: Develop Iteratively, Models and
visualization, UML, Software Development Life Cycle.
Rational Unified Process: Process, Phases in RUP, RUP
Workflows
Process, Lifecycle
Introduction to System
Concepts
 Introduction to System Concepts
Definition:
“All data are represented as discrete objects – User and other objects
may interact.”

“System is an interrelated set of components used within one unit,

working together for some purpose. ”

Example:
• A system in the payroll department keeps track of checks.
• An inventory system keeps track of supplies.
 Elements of the System
Control

Input Processing Output

Feedback
Boundary and Interface
Environment
 Elements of the
• Components : An irreducible partSystem
or aggregation of parts that makes up a system;
also called a subsystem.
• Interrelated components : Dependence of one part of the system on one or more
other system parts.
• Boundary : The line that marks the inside and outside of a system and that sets
off the system from its environment.
• Purpose : The overall goal or function of a system.
• Environment : Everything external to a system that interacts with the system.
• Interfaces : Point of contact where a system meets its environment or where
subsystems meet each other.
• Constraints : A limit to what a system can accomplish.
• Input : Inputs are the information that enters into the system for processing.
• Output : The main objective of a system is to get an output which is helpful for
• Man-made information systems are divided into three types
−
• Formal Information System − It is based on the flow of
information in the form of memos, instructions, etc., from
top level to lower levels of management.
• Informal Information System − This is employee based
system which solves the day to day work related problems.
• Computer Based System − This system is directly
dependent on the computer for managing business
applications. For example, automatic library system, railway
reservation system, banking system, etc.
 Information System
• Many organizations consider Information systems to be essential to
their ability to compete or gain competitive advantage.
Examples
• Transaction processing systems (TPSs)
• Management Information systems (MISs)
• Decision support systems (DSSs)
• Executive information system (EIS)
• Expert systems
• Communications and collaboration system
• Automation systems
 Other Important System Concepts
• Decomposition : System is divide into small components
1. Break a system into small, manageable, and understandable
subsystems
2. Concentrate on the part of the system relevant to a particular group
of users, without confusing users with unnecessary details
3. Build different parts of the system at independent times and
have the help of different analysts
• Modularity : System is divide into modules
• Coupling : Subsystems should be as independent as possible.
• Cohesion : Measure of the degree to which the elements of the module are
functionally related.
System Modelling
Modeling
• Develop software rapidly, efficiently, and effectively, with a minimum of
software scrap and rework - right people, the right tools, and the right
focus.
• Modeling is a proven and well-accepted engineering
technique
• Modeling is a central part of all the activities that lead up to the
deployment of good software.
• Build models to communicate the desired structure and behavior
of our system.
• Build models to visualize and control the system's architecture.
• Build models to better understand the system we are building, often
exposing opportunities for simplification and reuse
• Build models to manage risk.
 Why We Model
∙ The importance of modeling

∙ Four principles of modeling

∙ Object-oriented modeling

5
 Importance of modeling
⮚ A model is a simplification of reality.

We build models so that we can better understand the system we are

developing.

Through modeling, we achieve four aims

1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.

6
 Principles of Modeling
∙ Four 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.

4
3
 Object Oriented Modeling
• Several ways to approach a model.
• The two most common ways - an algorithmic perspective and from an object-
oriented perspective.
• Traditional view - an algorithmic perspective.
• Main building block of all software is the procedure or function.
• Developers to focus on issues of control and the decomposition of larger
algorithms into smaller ones.
• As requirements change and the system grows, systems built with an algorithmic
focus turn out to be very hard to maintain.
• The contemporary view - an object-oriented perspective.
• Main building block of all software systems is the object or class.
• Class is a description of a set of common objects.
• Every object has identity, state, and behavior.
• Example: Simple three-tier architecture for a billing system- a user interface,
middleware, and a database.
Introduction to
UML
 What is the UML?
• “The Unified Modeling Language is a family of
graphical notations, backed by a single meta- model,
that help in describing and designing software
systems, particularly software systems built using the
object-oriented style.”
• UML first appeared in 1997
• UML is standardized. Its content is controlled by the
Object Management Group (OMG), a consortium of
companies.
4 1
 What is the UML?
• Language
– UML is primarily a graphical language
that follows a precise syntax.
– UML 5 is the most recent version

23 23
• UML – Unified Modeling Language – Graphical lanuage
• Standard language – Software development
• Used to visualize, specify, construct and document
• Ranging from enterprise information systems to distributed Web-
based applications and hard real time embedded systems
• Addressing all the views needed to develop and then deploy such
systems.
• Not difficult to understand and to use.
• Three major elements:
• Basic building blocks
• Rules that dictate how these building blocks may be put together
• some common mechanisms that apply throughout the language.
• Conceptual and physical representation of a system
• Modeling yields an understanding of a system.
• No one model is ever sufficient.
• Need multiple models that are connected to one another in order to
understand.
• How to create but not what models should create and when should
create them.
• A well-defined process guide you in deciding what artifacts to
produce, what activities and what workers to use to create them and
manage them, and how to use those artifacts to measure and control
the project
 What is the UML?
• Unified
– UML combined the best from object-oriented
software modeling methodologies that were in
existence during the early 1990’s.
– Grady Booch, James Rumbaugh, and Ivor
Jacobson are the primary contributors to UML.

5 1
 What is the UML?
• Modeling
– Used to present a simplified view of reality in order to
facilitate the design and implementation of object-oriented
software systems.
– All creative disciplines use some form of modeling as
part of the creative process.
– UML is a language for documenting design
– Provides a record of what has been built.
– Useful for bringing new programmers up to speed.

5 1
 A Conceptual Model of the UML
• A conceptual model needs to be formed by an individual to
understand UML.
• UML contains three types of building blocks: things,
relationships, and diagrams.
• Things
– Structural things
• Classes, interfaces, collaborations, use cases, components,
and nodes.
– Behavioral things
• Messages and states.

5
2
 A Conceptual Model of the UML

– Grouping things
• Packages
– Annotational things
• Notes
• Relationships: dependency, association, generalization and
realization.
• Diagrams: class, object, use case, sequence, collaboration, statechart,
activity, component and deployment.

5
3
Conceptual Model of the UML
❖ Building Blocks of the UML:

The vocabulary of the UML encompasses three kinds

of building blocks:

1. Things
2. Relationships
3. Diagrams

54
 Conceptual Model of the UML
• 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

55
 Conceptual Model of the UML

• 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.
• Classes
• Interface
• Cases
• Active Classes
• Components
• Nodes
• Collabrations 12
 Conceptual Model of the
UML
Figure : Classes
Classes:
a 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

57
 Conceptual Model of the
UML
Interface:
an interface is a collection of operations that Figure :Interface
s
specify a service of a class or component. An
interface rarely stands alone. Rather, it is
typically attached to the class or component
that realizes the interface

58
 Conceptual Model of the
UML
• Collaborations:
a collaboration defines an interaction .These collaborations Figure:
therefore represent the implementation of patterns that make Collaborations
up a system. Graphically, a collaboration is rendered as an
ellipse with dashed lines, usually including only its name

59
 Conceptual Model of the
• UML
Use Cases:
Figure :Use Cases
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

60
 Conceptual Model of the
UML
• Active Classes:
Figure :Active
an active class is rendered just like a class, but with
Classes
heavy lines, usually including its name, attributes, and
operations

61
 Conceptual Model of the
UML
• Components:

Figure :Component
A component typically represents the s
physical packaging of otherwise logical
elements, such as classes, interfaces,
and collaborations. Graphically, a
component is rendered as a rectangle
with tabs, usually including only its
name

62
 Conceptual Model of the
UML
• Nodes:
a node is a physical element that exists at
run time and represents a computational Figure :Nodes
resource, generally having at least some
memory and, often, processing
capability. A set of components may
reside on a node and may also migrate
from node to node. Graphically, a node is
rendered as a cube, usually including
only its name

63
 Conceptual Model of the
UML
❖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. Messages
2. States

64
 Conceptual Model of the
UML
• Messages:
• an interaction is a behavior that comprises a set of
messages exchanged among a set ofobjects within a particular
context to accomplish a specific purpose. Graphically, a message is
rendered as a directed line, almost always including the name of its
operation.

• States:
• a 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.

65
 Conceptual Model of the
UML
❖Grouping Things:
• Grouping things are the organizational
parts of UML models. These are the boxes into
which a model can be decomposed. In all, there
is one primary kind of grouping thing, namely,
Figure:
packages.
Packages
• Packages:
• A package is a general-purpose mechanism
for organizing elements into groups.Graphically, a
package is rendered as a tabbed folder, usually
including only its name and, sometimes, its
contents
66
 Conceptual Model of the
UML
• Annotational Things:
• Annotational things are the explanatory parts of UML models. These
are the comments you may apply to describe, illuminate, and remark
about any element in a model.
• There is one primary kind of annotation thing, called a note. A note is
simply a symbol for rendering constraints and comments attached to an
element or a collection of elements.

Figure: Notes

24
The UML Is a Language for Visualizing:
Issues
• Communicating those conceptual models to others is error-prone.
• Can't understand unless you build models.
• Developer who cut the code never wrote down the models.
Solution:
• Writing models in the UML addresses the third issue: An explicit
model facilitates communication.
• The UML is more than just a bunch of graphical symbols.
• Each symbol in the UML notation is a well-defined semantics
The UML Is a Language for Specifying
• Building models that are precise, unambiguous, and complete.

The UML Is a Language for Constructing

• UML is not a visual programming language
• Possible to map from a model in the UML to a programming language
such as Java, C++, or Visual Basic, or even to tables in a relational
database or the persistent store of an object-oriented database.
• Mapping permits forward engineering.
• Reverse Engineering is also possible.
• Round-trip engineering: Ability to work in either a graphical or a
textual view, while tools keep the two views consistent.
• UML is sufficiently expressive and unambiguous to permit the direct
execution of models, the simulation of systems, and the
instrumentation of running systems.
The UML Is a Language for Documenting
• UML addresses the documentation of a system's architecture and all
of its details.
• UML also provides a language for expressing requirements and for
tests.
• Finally, the UML provides a language for modeling the activities of
project planning and release management.
 How We Got to the UML
• OO modeling languages made their
appearance in the late 70’s. Smalltalk was the first
widely used OO language.
• As the usefulness of OO programming became
undeniable, more OO modeling languages
began to appear.
• By the start of the 90’s there was a flood of
modeling languages, each with its own strengths
and weaknesses.
71 25
 How We Got to the UML

• In 1994 the UML effort officially began as a

collaborative effort between Booch and Rumbaugh.
Jacobson was soon after included in the effort.
• The goal of UML is to be a comprehensive modeling
language (all things to all people) that will facilitate
communication between all members of the
development effort.

72 25
 UML Diagrams
• UML supports 13 different types of diagrams
• Each diagram may be expressed with varying
degrees of detail
• Not all diagrams need be used to model a SW
system
• The UML does not offer an opinion as to which
diagrams would be most helpful for a particular type
of project

73 25
 UML
Diagrams

74 25
UML Diagrams
• A diagram is the graphical presentation of a set of elements, diagram
may contain any combination of things and relationships .
• Draw diagrams to visualize a system from different perspectives, so a
diagram is a projection into a system.
• Diagram represents an elided view of the elements that make up a
system.
• UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
Class diagrams
• Shows a set of classes, interfaces, and collaborations and their
relationships.
• Most common diagram found in modeling object-oriented systems.
• Address the static design view of a system.
• Include active classes, address the static process view of a system.
Object diagrams
• Shows a set of objects and their relationships.
• Represent static snapshots of instances of the things found in class
diagrams.
• Address the static design view or static process view of a system as do
class diagrams, but from the perspective of real or prototypical cases.
Use case diagrams
• Shows a set of use cases and actors (a special kind of class) and their relationships.
• 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, consisting of a set of objects and their relationships, including the
messages that may be dispatched among them.
• Address the dynamic view of a system.
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.
Statechart diagrams
• Shows a state machine, consisting of states, transitions, events, and
activities.
• 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, which is especially useful in modeling reactive
systems.
Activity diagrams
• Special kind of a statechart diagram that shows the flow from activity
to activity within a system.
• Address the dynamic view of a system.
• They are especially important in modeling the function of a system
Component diagrams
• Shows the organizations and dependencies among a set of components.
• 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 diagrams
• Model the physical architecture of a system.
• Deployment diagrams show the relationships between the software and hardware components in
the system and the physical distribution of the processing.
• Address the static deployment view of an architecture.
• They are related to component diagrams in that a node typically encloses one or more components.
1.Class diagram: A structural diagram that shows a set of classes,
interfaces, collaborations, and their relationships
2.Object diagram: A structural diagram that shows a set of objects and their
relationships
3.Use case diagram: A behavioral diagram that shows a set of use cases and
actors and their relationships
4.Sequence diagram: A behavioral diagram that shows an
interaction, emphasizing the time ordering of messages
5.Collaboration diagram: A behavioral diagram that shows an interaction,
emphasizing the structural organization of the objects that send and
receive messages
6.Statechart diagram: A behavioral diagram that shows a state machine,
emphasizing the event ordered behaviour of an object
7.Activity diagram: A behavioral diagram that shows a state machine,
emphasizing the flow from activity to activity
8.Component diagram: A structural diagram that shows a set of
components and their relationships
Rules of the UML
• 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
• Names - What you can call things, relationships, and diagrams
• Scope - The context that gives specific meaning to a name
• Visibility - How those names can be seen and used by others
• Integrity - How things properly and consistently relate to one another
• Execution - What it means to run or simulate a dynamic model
• UML is made simpler by the presence of four common mechanisms
that apply consistently throughout the language.
1. Specifications : provides a textual statement of the syntax and semantics of that building block.
2. Adornments
3. Common divisions
4. Extensibility mechanism
Stereotypes, Tagged values
and Constraints
Best Practices of Software Engineering
 Architecture
• Architecture refers to the different perspectives
from which a complex system can be viewed.
• The architecture of a software-intensive system is
best described by five interlocking views:
– Use case view: system as seen by users, analysts
and testers.
– Design view: classes, interfaces and collaborations that
make up the system.
– Process view: active classes (threads).
– Implementation view: files that comprise the system.
– Deployment view: nodes on which SW resides.

83 25
Architecture
• 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
• The organization of a software system
• The selection of the structural elements and their interfaces by which
the system is composed
• Their behavior, as specified in the collaborations among those elements
• 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.
Vocabulary System assembly
functionality configuration management
Implementation
Design View
View

Use case
Behavior view

Process View Deployment View

System topology
Distribution
Performance Delivery
Scalability installation
throughput
Use case view
• System encompasses the use cases that describe the behavior of
the system as seen by its end users, analysts, and testers.
• Doesn’t really specify the organization of a software system.
• Specify the forces that shape the system’s architecture.
• Static aspects of this view are captured in use case diagrams
• Dynamic aspects of this view are captured in interaction
diagrams, statechart diagrams, and activity diagrams.
Design view
• System encompasses the classes, interfaces, and collaborations that
form the vocabulary of the problem and its solution.
• Supports the functional requirements of the system.
• Static aspects of this view are captured in class diagrams and
object diagrams
• Dynamic aspects of this view are captured in interaction
diagrams, state chart diagrams, and activity diagrams.
Process view
• System encompasses the threads and processes that form the
system’s concurrency and synchronization mechanisms.
• Addresses the performance, scalability, and throughput of the system.
• Static and dynamic aspects - captured in the same kinds of diagrams as for the
design view, but with a focus on the active classes that represent these threads
and processes.
Implementation view
• System encompasses the components and files that are used to assemble
and release the physical system.
• Addresses the configuration management of the system's releases, made up
of somewhat independent components and files
• Static aspects of this view are captured in component diagrams; the
dynamic aspects of this view are captured in interaction diagrams,
state chart diagrams, and activity diagrams. .
Deployment view
• System encompasses the nodes that form the system's hardware
topology on which the system executes.
• Addresses the distribution, delivery, and installation of the parts that
make up the physical system.
• Static aspects of this view are captured in deployment diagrams; the
dynamic aspects of this view are captured in interaction diagrams,
statechart diagrams, and activity diagrams
Software Requirement Specification (SRS)
1. Introduction
(i) Purpose of this document : What
(ii) Scope of this document : Why
(iii) Overview : Summary

2.General description: Includes objective of user, a user characteristic, features, benefits, about
why its importance is mentioned.
3. Functional Requirements: Includes effects due to operation of program is fully explained.
4. Interface Requirements: How software program communicates with each other or users.
5.Performance Requirements: How a software system performs desired functions under specific
condition is explained.
6. Design Constraints: Limitation or restriction are specified and explained for design team.
7. Non-Functional Attributes : Required by software system for better performance.
8. Preliminary Schedule and Budget:
9. Appendices
 Software Development Life Cycle

• UML is involved in each phase of the software

development life cycle.
• The UML development process is
– Use case driven
– Architecture-centric
– Iterative and incremental

90 25
Software Development Life Cycle
• UML is largely process-independent, meaning that it is not tied to any
particular software development life cycle.
• Use case driven : use cases are used as a primary artifact for
establishing the desired behavior of the system, for verifying and
validating the system's architecture, for testing, and for
communicating among the stakeholders of the project.
• Architecture-centric: System's architecture is used as a primary
artifact for conceptualizing, constructing, managing, and evolving the
system under development.
• Iterative process: Managing a stream of executable releases.
Continuous integration of the system's architecture to produce these
releases, with each new release embodying incremental
improvements over the other.
Inception:
• Seed idea for the development is brought up to the point of being - at least internally -
sufficiently well-founded.
Elaboration:
• Product vision and its architecture are defined. System’s requirements are articulated,
prioritized, and baselined.
• Range from general vision statements to precise evaluation criteria, each specifying
particular functional or nonfunctional behavior and each providing a basis for testing.
Construction:
• Software is brought from an executable architectural baseline to being ready to be
transitioned to the user community.
• System's requirements and especially its evaluation criteria are constantly reexamined
against the business needs of the project, and resources are allocated as appropriate to
actively attack risks to the project.
Transition:
• Software is turned into the hands of the user community.
• System is continuously improved, bugs are eradicated, and features that didn't make an
earlier release are added.
• An iteration is a distinct set of activities, with a baselined plan and evaluation criteria that
result in a release, either internal or external
 Rational Unified Process (RUP)
• A process is a set of partially ordered steps intended to reach a goal.
• Rational Unified Process (RUP) is a software development process for object-
oriented models.
• The UML is largely process-independent. RUP is well-suited to the UML.
• Goal: Enable the production of highest quality software that meets end-user
needs within predictable schedules and budgets.
• Management side: Provides a disciplined approach on how to assign tasks
and responsibilities.
Characteristics of Process:
• Iterative process
• Models
• Architecture centric
• Use Case driven
• Object oriented techniques
• Configurable process
• Quality control and risk management
Phases and iterations:
• A phase is the span of time between two major milestones of the process - well-defined
set of objectives are met, artifacts are completed, and decisions.
1. Inception: Establish the business case for the project
2. Elaboration: Establish a project plan and a sound architecture
3. Construction: Grow the system
4. Transition: Supply the system to its end users
• An iteration represents a complete development cycle, from requirements capture in
analysis to implementation and testing, that results in the release of an executable
project.
Phases:
Inception
• Establish the business case for the system and delimit the project's scope.
• The business case includes success criteria, risk assessment, estimates of the resources
needed, and a phase plan showing a schedule of major milestones.
• Create an executable prototype that serves as a proof of concept.
• At the end, Examine the life cycle objectives of the project and decide whether to
proceed with full-scale development.
Elaboration
• Goal: Analyze the problem domain, establish a sound architectural foundation, develop
the project plan, and eliminate the highest risk elements of the project.
• Architectural decisions must be made with an understanding of the whole system
• Describe most of the system's requirements.
• Verify the architecture: Implement a system that demonstrates the architectural choices
and executes significant use cases.
• At the end, Examine the detailed system objectives and scope, the choice of architecture,
and the resolution of major risks, and decide whether to proceed with construction.
Construction
• Iteratively and incrementally develop a complete product that is ready to
transition to its user community.
• Describing the remaining requirements and acceptance criteria, fleshing out the
design, and completing the implementation and test of the software.
• At the end , decide if the software, sites, and users are all ready to go operational.
Transition
• Deploy the software to the user community.
• Require additional development in order to adjust the system, correct some
undetected problems, or finish some features that have been postponed.
• Starts with a beta release of the system, which is then replaced with the
production system.
• At the end, decide whether the life cycle objectives of the project have been met
and determine if you should start another development cycle.
Process Workflows:
The Rational Unified Process consists of nine process workflows.
1. Business modeling Describes the structure and dynamics of the organization
2. Requirements Describes the use case— based method for eliciting requirements
3. Analysis and design Describes the multiple architectural views
4.Implementation Takes into account software development, unit test, and
integration
5. Test Describes test cases, procedures, and defect-tracking metrics
6. Deployment Covers the deliverable system configuration
7. Configuration management Controls changes to and maintains the integrity of a
project’s artifacts
8.Project Management Describes various strategies of working with an iterative
process
9. Environment Covers the necessary infrastructure required to develop a system
END