Software Engineering

UNIT – I (Cont…)
OUTLINE
• SpecializedProcessModel
-TheFormalMethodsModel
-Aspect-OrientedSoftwareDevelopment
• TheUnifiedProcess
-PhasesoftheUnifiedProcess

 The formal methods model encompasses a set of
activities that leads to formal mathematical specification of
computer software.
 Formal methods enable you to specify, develop, and
verify a computer-based system by applying a rigorous,
mathematical notation.
 A variation on this approach, called clean room software
engineering, is currently applied by some software
development organizations.
 When formal methods are used during development,
they provide a mechanism for eliminating many of the
problems that are difficult to overcome using other
software engineering paradigms.

 Ambiguity, incompleteness, and inconsistency can be
discovered and corrected more easily—not through the
review, but through the application of mathematical
analysis.
 When formal methods are used during design, they serve
as a basis for program verification and “discover and correct
errors” that might otherwise go undetected.
 The development of formal models is currently quite
time consuming and expensive.
 Because few software developers have the necessary
background to apply formal methods, extensive training is
required.
 It is difficult to use the models as a communication
mechanism for technically unsophisticated customers.

 Localized software characteristics are modeled as
components (e.g., object oriented classes) and then
constructed within the context of a system architecture.
 As modern computer-based systems become more
sophisticated (and complex), certain concerns—customer
required properties or areas of technical interest—span the
entire architecture.
 Some concerns are high-level properties of a system (e.g.,
security, fault tolerance).Other concerns affect functions
(e.g., the application of business rules), while others are
systemic (e.g., task synchronization or memory
management).
 When concerns cut across multiple system functions,
features, and information, they are often referred to as
cross cutting concerns.

 Aspectual requirements define those crosscutting concerns that
have an impact across the software architecture.
 Aspect-oriented software development(AOSD), often referred to as
aspect-oriented programming(AOP),is a relatively new software
engineering paradigm that provides a process and methodological
approach for defining, specifying, designing, and constructing
aspects—“mechanisms beyond subroutines and inheritance for
localizing the expression of a crosscutting concern”.
 Aspect-oriented component engineering(AOCE):AOCE uses a
concept of horizontal slices through vertically-decomposed software
components, called “aspects”.
 Components may provide or require one or more “aspect details”
relating to a particular aspect, such as a viewing mechanism,
extensible affordance and interface kind (user interface aspects);
 event generation,
 transport and receiving (distribution aspects);
 data store/retrieve and indexing (persistency aspects);
 authentication,
 encoding and access rights (security aspects);

 transaction atomicity,
 concurrency control and logging strategy (transaction
aspects); and soon.
 Each aspect detail has a number of properties, relating
to functional and/or non-functional characteristics of
the aspect detail.
 The evolutionary model is appropriate as aspects are
identified and then constructed.
 The parallel nature of concurrent development is
essential because aspects are engineered
independently.

 The unified process related to “use case driven,
architecture-centric, iterative and incremental” software
process.
 The Unified Process is an attempt to draw on the best
features and characteristics of traditional software
process models.
 The Unified Process recognizes the importance of
customer communication and streamlined methods for
describing the customer’s view of a system.
 It emphasizes the important role of software architecture
and “helps the architect focus on the right goals.
 It suggests a process flow that is iterative and
incremental.
 During the early 1990s James Rumbaugh [Rum91], Grady
Booch [Boo94], and Ivar Jacobson [Jac92] began working
on a “unified method”.

 The result was UML—a unified modeling language that
contains a robust notation for the modeling and development
of object-oriented systems.
 By 1997, UML became a de facto industry standard for object-
oriented software development.
 UML is used to represent both requirements and design
models.
 UML provided the necessary technology to support object-
oriented software engineering practice, but it did not provide
the process framework.
 Over the next few years, Jacobson, Rumbaugh, and Booch
developed the Unified Process, a framework for object-
oriented software engineering using UML.
 Today, the Unified Process (UP) and UML are widely used on
object-oriented projects of all kinds.
 The iterative, incremental model proposed by the UP can and
should be adapted to meet specific project needs.

 The above figure depicts the different phases in Unified
Process.
 The inception phase of the UP encompasses both
customer communication and planning activities.
By collaborating with stakeholders, business
requirements for the software are identified;
a rough architecture for the system is proposed; and
a plan for the iterative, incremental nature of the
ensuing project is developed.
Fundamental business requirements are described.
The architecture will be refined.
Planning identifies resources, assesses major risks,
defines a schedule, and establishes a basis for the
phases.

 The elaboration phase encompasses the communication and
modeling activities of the generic process model.
Elaboration refines and expands the preliminary use cases
that were developed as part of the inception phase and
expands the architectural representation to include five
different views of the software—the use case model, the
requirements model, the design model, the implementation
model, and the deployment model.
In some cases, elaboration creates an “executable
architectural baseline” that represents a “first cut” executable
system.
The architectural baseline demonstrates the viability of the
architecture but does not provide all features and functions
required to use the system.
In addition, the plan is carefully reviewed.
Modifications to the plan are often made at this time.

 The construction phase of the UP is identical to the
construction activity defined for the generic software process.
Using the architectural model as input, the construction phase
develops or acquires the software components that will make
each use case operational for end users.
The elaboration phase reflect the final version of the
software increment.
All necessary and required features and functions for the
software increment are then implemented in source code.
As components are being implemented, unit tests are
designed and executed for each.
In addition, integration activities are conducted.
Use cases are used to derive a suite of acceptance tests that
are executed prior to the initiation of the next UP phase.

 The transition phase of the UP encompasses the latter
stages of the generic construction activity and the first
part of the generic deployment (delivery and feedback)
activity.
 Software is given to end users for beta testing and user
feedback reports both defects and necessary changes.
 In addition, the software team creates the necessary
support information (e.g., user manuals, troubleshooting
guides, installation procedures) that is required for the
release.
 At the conclusion of the transition phase, the software
increment becomes a usable software release.

 The production phase of the UP coincides with the
deployment activity of the generic process.
During this phase, the ongoing use of the software is
monitored, support for the operating environment
(infrastructure) is provided, and defect reports and
requests for changes are submitted and evaluated.
It is likely that at the same time the construction,
transition, and production phases are being conducted.
Work may have already begun on the next software
increment.
This means that the five UP phases do not occur in a
sequence, but rather with staggered concurrency.

 A software engineering workflow is distributed across all
UP phases.
 In the context of UP, a workflow is a task set
 That is, a workflow identifies the tasks required to
accomplish an important software engineering action and
the work products that are produced as a consequence of
successfully completing the tasks.
 It should be noted that not every task identified for a UP
workflow is conducted for every software project.
 The team adapts the process (actions, tasks, subtasks,
and work products) to meet.

Software Engineering

More Related Content

What's hot (20)

Similar to Software Engineering (20)

More from JayaKamal (8)

Recently uploaded (20)

Software Engineering