OBJECT ORIENTED SOFTWARE ENGINEERING

UNIT-2
Architecture
System development is model building
The work that occurs when we develop computer support to aid an organization. System
development is model building. It starts when a requirement of system identified and Specification
can be used for contract and to plan and control the development process. It is a complex process
handle poorly. OOSE can used from start to end of system life cycle. It is based on three
technologies:

• Object oriented programming

• Conceptual modeling
• Block design

It consists of five different models:

• The requirement model

Aims to capture the functional requirements
• Analysis model
Give the system a robust and changeable object structure
• Design model
Adopt and refine the object structure to the current implementation environment
• Implementation model
Implement the system
• Test model
Verify the system
Seamless transition between the models is important. The method layer define the transformation
rules. For maintainability traceability is very important between the models.
Models are tightly coupled to the architecture, and aim is to find concepts which are simple
to learn and use. It simplify our understanding of the system and provide us with a changeable
model of the system. These models are sufficiently powerful to express the information which is
required to model the system. These models are sufficiently defined that different people can
discuss the system in terms of these concepts without being misunderstood.

model architecture
Software architecture involves the high level structure of software system abstraction, by
using decomposition and composition, with architectural style and quality attributes. A
software architecture design must conform to the major functionality and performance
requirements of the system, as well as satisfy the non-functional requirements such as
reliability, scalability, portability, and availability.
A software architecture must describe its group of components, their connections,
interactions among them and deployment configuration of all components.
A software architecture can be defined in many ways −
• UML (Unified Modeling Language) − UML is one of object-oriented solutions used in
software modeling and design.
• Architecture View Model (4+1 view model) − Architecture view model represents the
functional and non-functional requirements of software application.
• ADL (Architecture Description Language) − ADL defines the software architecture formally
and semantically.

UML
UML stands for Unified Modeling Language. It is a pictorial language used to make
software blueprints. UML was created by Object Management Group (OMG). The UML
1.0 specification draft was proposed to the OMG in January 1997. It serves as a standard
for software requirement analysis and design documents which are the basis for
developing a software.
UML can be described as a general purpose visual modeling language to visualize,
specify, construct, and document a software system. Although UML is generally used to
model software system, it is not limited within this boundary. It is also used to model non
software systems such as process flows in a manufacturing unit.
The elements are like components which can be associated in different ways to make a
complete UML picture, which is known as a diagram. So, it is very important to
understand the different diagrams to implement the knowledge in real-life systems. We
have two broad categories of diagrams and they are further divided into sub-categories
i.e. Structural Diagrams and Behavioral Diagrams.

Structural Diagrams
Structural diagrams represent the static aspects of a system. These static aspects
represent those parts of a diagram which forms the main structure and is therefore
stable.
These static parts are represented by classes, interfaces, objects, components and
nodes. Structural diagrams can be sub-divided as follows −

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram
• Package diagram
• Composite structure
The following table provides a brief description of these diagrams −

Sr.No. Diagram & Description

1
Class
Represents the object orientation of a system. Shows how classes are statically related.

2
Object
Represents a set of objects and their relationships at runtime and also represent the
static view of the system.

3
Component
Describes all the components, their interrelationship, interactions and interface of the
system.

4
Composite structure
Describes inner structure of component including all classes, interfaces of the
component, etc.

5
Package
Describes the package structure and organization. Covers classes in the package and
packages within another package.
6
Deployment
Deployment diagrams are a set of nodes and their relationships. These nodes are
physical entities where the components are deployed.

Behavioral Diagrams

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspects
are basically the changing/moving parts of a system. UML has the following types of
behavioral diagrams −

• Use case diagram

• Sequence diagram
• Communication diagram
• State chart diagram
• Activity diagram
• Interaction overview
• Time sequence diagram
The following table provides a brief description of these diagram −

Sr.No. Diagram & Description

1
Use case
Describes the relationships among the functionalities and their internal/external
controllers. These controllers are known as actors.

2
Activity
Describes the flow of control in a system. It consists of activities and links. The flow can
be sequential, concurrent, or branched.

3
State Machine/state chart
Represents the event driven state change of a system. It basically describes the state
change of a class, interface, etc. Used to visualize the reaction of a system by
internal/external factors.

4
Sequence
Visualizes the sequence of calls in a system to perform a specific functionality.
5
Interaction Overview
Combines activity and sequence diagrams to provide a control flow overview of system
and business process.

6
Communication
Same as sequence diagram, except that it focuses on the object’s role. Each
communication is associated with a sequence order, number plus the past messages.

7
Time Sequenced
Describes the changes by messages in state, condition and events.

Architecture View Model

A model is a complete, basic, and simplified description of software architecture which
is composed of multiple views from a particular perspective or viewpoint.
A view is a representation of an entire system from the perspective of a related set of
concerns. It is used to describe the system from the viewpoint of different stakeholders
such as end-users, developers, project managers, and testers.

4+1 View Model

The 4+1 View Model was designed by Philippe Kruchten to describe the architecture of
a software–intensive system based on the use of multiple and concurrent views. It is
a multiple view model that addresses different features and concerns of the system. It
standardizes the software design documents and makes the design easy to understand
by all stakeholders.
It is an architecture verification method for studying and documenting software
architecture design and covers all the aspects of software architecture for all
stakeholders. It provides four essential views −
• The logical view or conceptual view − It describes the object model of the design.
• The process view − It describes the activities of the system, captures the concurrency and
synchronization aspects of the design.
• The physical view − It describes the mapping of software onto hardware and reflects its
distributed aspect.
• The development view − It describes the static organization or structure of the software in
its development of environment.
This view model can be extended by adding one more view called scenario view or use
case view for end-users or customers of software systems. It is coherent with other four
views and are utilized to illustrate the architecture serving as “plus one” view, (4+1) view
model. The following figure describes the software architecture using five concurrent
views (4+1) model.

Why is it called 4+1 instead of 5?

The use case view has a special significance as it details the high level requirement of
a system while other views details — how those requirements are realized. When all
other four views are completed, it’s effectively redundant. However, all other views would
not be possible without it. The following image and table shows the 4+1 view in detail –

Logical Process Development Physical Scenario

Description Shows the Shows the processes Gives building Shows the Shows the
component / Workflow rules of block views of installation, design is
(Object) of system system and how system and configuration and complete by
as well as their those processes describe static deployment of performing
interaction communicate, organization of the software validation and
focuses on dynamic system modules application illustration
view of system

Viewer / End-User, Integrators & Programmer and System engineer, All the views of
Stake Analysts and developers software project operators, system their views and
holder Designer managers administrators evaluators
and system
installers

Consider Functional Non Functional Software Module Nonfunctional System

requirements Requirements organization requirement Consistency
(Software regarding to and validity
management underlying
reuse, constraint of hardware
tools)
 UML – Class, State, Activity Diagram Component, Deployment Use case
Diagram Object, sequence, Package diagram diagram diagram
Communication
Diagram

Architecture Description Languages (ADLs)

An ADL is a language that provides syntax and semantics for defining a software
architecture. It is a notation specification which provides features for modeling a software
system’s conceptual architecture, distinguished from the system’s implementation.
ADLs must support the architecture components, their connections, interfaces, and
configurations which are the building block of architecture description. It is a form of
expression for use in architecture descriptions and provides the ability to decompose
components, combine the components, and define the interfaces of components.
An architecture description language is a formal specification language, which describes
the software features such as processes, threads, data, and sub-programs as well as
hardware component such as processors, devices, buses, and memory.
It is hard to classify or differentiate an ADL and a programming language or a modeling
language. However, there are following requirements for a language to be classified as
an ADL −
• It should be appropriate for communicating the architecture to all concerned parties.
• It should be suitable for tasks of architecture creation, refinement, and validation.
• It should provide a basis for further implementation, so it must be able to add information to
the ADL specification to enable the final system specification to be derived from the ADL.
• It should have the ability to represent most of the common architectural styles.
• It should support analytical capabilities or provide quick generating prototype
implementations.

requirement model
Requirements modeling in software engineering identifies the requirements that a software
application or system must meet in order to solve the business problem. Requirements are
divided into functional (what the system will have to do) and non-functional (constraints within
which the system will have to perform).
analysis model
An object model describing the realization of use cases, and which serves as an abstraction of the
Artifact: Design Model. The Analysis Model contains the results of use case analysis, instances
of the Artifact: Analysis Class. The Analysis Model is an optional artifact.

design model
The design model is an object model describing the realization of use cases, and serves as an
abstraction of the implementation model and its source code. The design model is used as
essential input to activities in implementation and test.

implementation model
An implementation model is a representation of how a system (application, service, interface
etc.) actually works. It's often described with system diagrams and pseudo code, and later
translated into real code.
 Analysis
System development based on user requirement
1. Developers must be trained not to add any features or capabilities beyond those stated in the approved
requirements. Industry experience is that developers add capabilities, increasing the scope of the product
and adding to the effort required throughout the system's lifecycle.

2. Methods such as requirements workshops (conducted as needed), storyboards, requirements reviews,

idea reduction, role playing, and prototyping should be used. See Dean Leffingwell, Managing Software
Requirements: A Unified Approach, for a lot of experience and suggestions.

3. "What if" questions should be asked, focusing on the boundary conditions, exceptions, and unusual
events.

4. A careful manual review and analysis of the complete set of requirements, supported by the user and
utilizing appropriate automated tools, will be needed to ensure consistency in the requirements set.

5. Developers, customers, and other stakeholders need to rank the individual requirements in terms of their
importance to the customer. This technique helps to manage the project scope. Requirements should
also be ranked in terms of their stability. This is only a beginning to defining the releases of the product.
Data dependencies must be considered as well. See Bill Wiley, Essential System Requirements: A
Practical Guide to Event-Driven Methods, Chapters 8 and 9 for discussion of data/process interaction and
transition to physical design.

6. One of the most difficult requirements challenges is writing the requirements detailed enough to be well
understood without over-constraining the system and annoying users with details intended to remove
ambiguity. Here are some guidelines:

• Use natural language whenever possible.

• Use pictures and diagrams to further illustrate the intent.
• When in doubt, ask for more information.
• Augment specifications with more formal methods when it is critical not to be misunderstood (life-
and-death situations or grave consequences of erroneous behavior).
• Train people to recognize the problem and the solution.
• Use diagrams and structured pseudo-code to describe complex technical specifications.

7. We know that the requirements will change for several reasons:

1. External factors:
a. Change in the problem (the business) we are attempting to solve.
b. Users change their minds.
c. The external environment has changed, creating new constraints and/or opportunities (for
example, the availability of the Internet and the World Wide Web).
d. The very existence of the new system causes the requirements for the system to change!

2. Internal factors:

a. Failure to discover the real requirements during the initial requirements-gathering effort.
b. Failure to create a practical process to help manage changes.

• Requirements leakage:
a. Direct user/customer requests to programmers.
 b. Functionality inserted by programmers "because it's a good thing."

Change must be managed. Here are some guidelines:

• Recognize that change is inevitable and provide methods to deal with it.
• Baseline the requirements.
• Establish a single channel to control change (such as the joint team).
• Use a change-control system to capture changes. Keep requirements under vigorous configuration
management (CM).
• Manage changes hierarchically so that the downward ripple effect of a change will be highlighted by the
traceability in the requirements tool.
• Industry data show that a change of 30% in the requirements results in doubling of the costs of the
project. The joint team is critical to provide joint customer and contractor responsibility for the
requirements and for the impacts of any approved changes.

Use case model

A use-case model is a model of how different types of users interact with the system to solve a
problem. As such, it describes the goals of the users, the interactions between the users and the system,
and the required behavior of the system in satisfying these goals.

A use-case model consists of a number of model elements. The most important model elements are: use
cases, actors and the relationships between them.

A use-case diagram is used to graphically depict a subset of the model to simplify

communications. There will typically be several use-case diagrams associated with a given model, each
showing a subset of the model elements relevant for a particular purpose. The same model element may
be shown on several use-case diagrams, but each instance must be consistent. If tools are used to
maintain the use-case model, this consistency constraint is automated so that any changes to the model
element (changing the name for example) will be automatically reflected on every use-case diagram that
shows that element.

The use-case model may contain packages that are used to structure the model to simplify analysis,
communications, navigation, development, maintenance and planning.

Much of the use-case model is in fact textual, with the text captured in the Use-Case Specifications that
are associated with each use-case model element. These specifications describe the flow of events of the
use case.

The use-case model serves as a unifying thread throughout system development. It is used as the
primary specification of the functional requirements for the system, as the basis for analysis and design,
as an input to iteration planning, as the basis of defining test cases and as the basis for user
documentation.

interface descriptions
An interface description language or interface definition language (IDL), is a specification
language used to describe a software component's application programming interface (API). IDLs
describe an interface in a language-independent way, enabling communication between software
components that do not share one language, for example, between those written in C++ and those
written in Java.
IDLs are commonly used in remote procedure call software. In these cases the machines at either
end of the link may be using different operating systems and computer languages. IDLs offer a
bridge between the two different systems.
Software systems based on IDLs include Sun's ONC RPC, The Open Group's Distributed
Computing Environment, IBM's System Object Model, the Object Management
Group's CORBA (which implements OMG IDL, an IDL based on DCE/RPC) and Data Distribution
Service, Mozilla's XPCOM, Microsoft's Microsoft RPC (which evolved
into COM and DCOM), Facebook's Thrift and WSDL for Web services.

Problem domain objects

In a nutshell anything substantial you find around a problem domain is considered a domain
object. In your case you have the receptionist, the SMS, the reservation and the customer. Now
what you are doing is to classify these objects (make classes). And that's called problem
domain analysis.

entity objects
Entity objects are classes that encapsulate the business model, including rules, data,
relationships, and persistence behavior, for items that are used in your business application. For
example, entity objects can represent. the logical structure of the business, such as product
lines, departments, sales, and regions.

control objects
Entities are objects representing system data: Customer, Transaction, Cart, etc. Boundaries
are objects that interface with system actors: user interfaces, gateways, proxies, etc.
Controllers are objects that mediate between boundaries and entities. They orchestrate the
execution of commands coming from the boundary.
 Code Design Improvement
Refactoring
Code refactoring is the process of restructuring existing computer code—changing the factoring—
without changing its external behavior. Refactoring is intended to improve nonfunctional attributes of
the software. Advantages include improved code readability and reduced complexity; these can
improve source-code maintainability and create a more expressive internal architecture or object
model to improve extensibility.
Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is
(usually) a tiny change in a computer program's source code that either preserves the behaviour of
the software, or at least does not modify its conformance to functional requirements.
Many development environments provide automated support for performing the mechanical aspects
of these basic refactorings. If done well, code refactoring may help software developers discover and
fix hidden or dormant bugs or vulnerabilities in the system by simplifying the underlying logic and
eliminating unnecessary levels of complexity. If done poorly it may fail the requirement that external
functionality not be changed, introduce new bugs, or both.
By continuously improving the design of code, we make it easier and easier to work with. This is in
sharp contrast to what typically happens: little refactoring and a great deal of attention paid to
expediently adding new features. If you get into the hygienic habit of refactoring continuously, you'll
find that it is easier to extend and maintain code.

Anti patterns
An anti-pattern is a common response to a recurring problem that is usually ineffective and risks
being highly counterproductive.[1][2] The term, coined in 1995 by Andrew Koenig,[3] was inspired by a
book, Design Patterns, which highlights a number of design patterns in software development that its
authors considered to be highly reliable and effective.
The term was popularized three years later by the book AntiPatterns, which extended its use beyond
the field of software design to refer informally to any commonly reinvented but bad solution to a
problem. Examples include analysis paralysis, cargo cult programming, death
march, groupthink and vendor lock-in.

Visitor Patterns
In object-oriented programming and software engineering, the visitor design pattern is a way of
separating an algorithm from an object structure on which it operates. A practical result of this
separation is the ability to add new operations to existing object structures without modifying the
structures. It is one way to follow the open/closed principle.
In essence, the visitor allows adding new virtual functions to a family of classes, without modifying
the classes. Instead, a visitor class is created that implements all of the appropriate specializations
of the virtual function. The visitor takes the instance reference as input, and implements the goal
through double dispatch.