Object Oriented System Analysis and Desig
Object Oriented System Analysis and Desig
Introduction
What is Object Oriented System Analysis and Design?
As a whole Object Oriented system analysis and design is a part of object oriented programing
that helps us analyze and design an application based on that system’s object models( the logical
components of the system that interact with one another). But we can also go a little deeper and
define it separately. So Object Oriented Analysis is a stage of analysis that takes place during the
software development life cycle, that aims to model the functional requirements of the software
while remaing completely independent of any potential implemetation requirements. And
Object Oriented Design is just the extention of the object oriented analysis process that
preceded it, except with a critical warning: the consideration and implementation of constraints.
The key difference between the two is that structured paradigm’s main focus is on the
procedures of the system, It uses System Development Life Cycle(SDLC) methodology for
different purposes like planning, analyzing, designing, implementing and supporting an
information system. And Object Oriented paradigm’s main focus is on the data structure and
real-world objects that are important, it uses incremental or iterative methodology to refine and
extend our design.
Object Orientation is what’s referred to as a programming paradigm. It’s not a language itself
but a set of concepts that is supported by many languages. If Everything we do in these language
is Object oriented, it means, we are oriented or focused around objects. Now in an object
oriented language, this one large program will instead be split apart into self contained objects,
almost like having several mini-programs, each object represents a different part of the
application. And each object contains its own data and its own logic, and they communicate
between themselves. These objects aren’t random. They represent the way you talk and think
about the problem you are trying to solve in your real life. They represent things like employees,
images, bank accounts, spaceships, asteroids, video segment, audio files, or whatever exists in
your program.
Well for one it has modularity for easier troubleshooting, meaning if something went wrong you
will know exactly where to look to fix it. And whats more is its reuse of code through inheritance,
meaning that you could just put the commonalities out for reuse if the objects use them. Third it
is flexible through polymorphism if there are unique traits in the function its polymorphism
allows it to shape shift and adapt to whichever class it’s in. And the forth is that its effective
problem solving, while writing languages like C could feel difficult cause of its top-down form
object orientation allows us to break down and make our software easy and bite-sized to solve
problems.
<--!The object oriented software process (enhanced life cycle of unified process)-->?
Requirements can be devided into functional and non-functional requirements where fucntional
is defined as process, information, and interactions. These are the desired functionalities that
the client wants to build and describe the interaction between the system and its enviroment.
And non-functional requirements are those that address operational and technical
requirements, like encryption, security, hosting, enviroment disaster recovery, business
continuity.
An essential use case sometimes called a business use case, is simplified, abstract, generalized
use case that captures the intentions of a user in a technology and implementation independent
manner. Essential use cases are typically written in two column format, the column on the left
indicates the intention of the user/actor and the coulumn on the right the system’s responsiblity
to hopefully respond.
An essential user interface prototype also known as an abstract prototype or paper prototype is
a low fidleity model, or prototype of the UI for your system. For your system. It represents the
general ideas behind the UI, but not the exact details.
A CRC(Class Responsiblity Collaborator ) model is a collection of CRC cards that represent whole
or part of an application or problem domain. The most common use for CRC models, the one
that this white paper addresses, is to gather and define the user requirements for an object-
oriented application.
The Supplementary Specifications capture the system requirements that are not readily
captured in the use cases of the use case model. Such requiremnts include: Legal and regulatory
requirement, and application standards.
Requirement verification is a quality check of the analyzed requirements. This task involves
making sure your requirements are correct and complete and that they meet the quality
standards defined for them. The techniques used (as defined by Babok) are acceptance and
evaluation criteria.
In the system analysis or object-oriented analysis phase of software development, the system
requirements are determined, the classes are identified and the relationships among classes are
identified.
The dynamic model is used to express and model the behaviour of the system over time. It
includes support for activity diagrams, state diagrams, sequence diagrams and extensions
including business process modeling.
Sequence diagrams are used to display the interaction between users, screens, objects and
entities within the system. It provides a sequential map of message passing between objects
over time.
Activity diagrams are used to show how different workflows in the system are constructed, how
they start and the possibly many decision paths that can be taken from start to finish.
A conceptual class diagram is used to understand and analyze a problem domain. A detailed
class diagram is a design artifact, where many things may have been optimized away.
A common architectural strategy, some might call it a pattern, is to layer the architecture of a
system into several layers/strata. Some strategies simply define N layers stacked on top of each
other where layer J interacts only with layers J-1 and J+1. That's an interesting theory, and it
clearly makes sense from a logical point of view, but in practice I've found that it isn't quite so
simple.
Class model defines the structure of the entire system by identifying the static structure of
objects in that system. A class model defines attributes and operations for the objects of each
class and also the relationship between the objects in the systems. Class Modeling focuses on
static system structure in terms of classes (Class, Data Type, Interface and Signal items),
Associations and on characteristics of Classes (Operations and Attributes).
State chart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are changed
by events. State chart diagrams are useful to model the reactive systems. State chart diagram
describes the flow of control from one state to another state. States are defined as a condition in
which an object exists and it changes when some event is triggered. The most important
purpose of State chart diagram is to model lifetime of an object from creation to termination.
The Collaboration Model reveals how the people in the user’s world communicate and
coordinate to get activities done, often using technology.
UML communication diagrams, like the sequence diagrams is a kind of interaction diagram,
shows how objects interact. A communication diagram is an extension of object diagram that
shows the objects along with the messages that travel from one to another. In addition to the
associations among objects, communication diagram shows the messages the objects send
each other.
User interface (UI) design is the process designers use to build interfaces in software or
computerized devices, focusing on looks or style. Designers aim to create interfaces which users
find easy to use and pleasurable. UI design refers to graphical user interfaces and other form.
e.g. voice-controlled interfaces.
In unit testing, the individual classes are tested. It is seen whether the class attributes are
implemented as per design and whether the methods and the interfaces are error-free.
Subsystem testing involves testing a particular module or a subsystem and is the responsibility of
the subsystem lead. It involves testing the associations within the subsystem as well as the
interaction of the subsystem with the outside.
System testing involves testing the system as a whole and is the responsibility of the quality-
assurance team. The team often uses system tests as regression tests when assembling new
releases.