MODULE 3
WORKFLOW OF SOFTWARE
LIFECYCLE
Requirement
• A requirement is a statement describing either
1) an aspect of what the proposed system
must do, or
2) a constraint on the system’s development.
• In either case, it must contribute in some way
towards adequately solving the customer’s
problem; the set of requirements as a whole
represents a negotiated agreement among all
stakeholders.
Requirement Workflow
• Requirements engineering provides the appropriate
mechanism for understanding what the customer wants,
analyzing need, assessing feasibility, negotiating a
reasonable solution, specifying the solution unambiguously,
validating the specification, and managing the
requirements as they are transformed into an operational
system
• The requirements engineering process can be described in
five distinct steps
–
–
–
–
–
–
requirements elicitation
requirements analysis and negotiation
requirements specification
system modeling
requirements validation
requirements management
Types of requirements
• Requirements can be divided into four major
types: functional, quality, platform and
process.
• Requirements documents normally include at
least the first two types.
NOTE
• Non-functional requirements
• Quality, platform and process requirements
used to be collectively called non-functional
requirements.
• However, that term has fallen into disfavor
and therefore is not used.
Functional requirements
• Functional requirements describe what the system should do;
in other words, they describe the services provided for the
users and for other systems.
• The functional requirements should include
• 1) everything that a user of the system would need to know
regarding what the system does, and
• 2) everything that would concern any other system that has to
interface to this system.
The functional requirements can be further categorized as
follows:
• What inputs the system should accept, and under what conditions.
– This includes data and commands both from the users and from other
systems.
• What outputs the system should produce, and under what conditions.
– Outputs can be to the screen or printed.
– They can also be transmitted to other systems, such as special I/O
devices, clients or servers.
• What data the system should store that other systems might use.
– This is a special kind of output that will eventually become an input to
other systems.
– Data which is stored for the exclusive use of this system (e.g. the
specifics of a file format used to temporarily back up some data) can be
ignored until the design stage.
• What computations the system should perform.
• The computations should be described at a level that all the readers
can understand.
• For example, you would describe a sorting process by saying that the
result is to be ordered in ascending sequence according to the account
number. You would not normally specify the particular algorithm to be
used.
• The timing and synchronization of the above.
• Not all systems involve timing and synchronization – this category of
functional requirements is of most importance in hard real-time
systems that do such things as control hardware devices (e.g.
telecommunications systems, systems that control power plants or
factories, and systems that run automobiles and airplanes).
• An individual requirement often covers more than one of the
above categories.
• For example, the requirements for a word processor might
say, ‘when the user selects “word count”, the system displays
a dialog box listing the number of characters, words,
sentences, lines, paragraphs, pages, and words per sentence
in the current document.’
• This requirement clearly describes input (selecting ‘word
count’), output (what is displayed) and computation (counting
all the necessary information, and computing the average
words per sentence).
Quality requirements
• Quality requirements ensure the system possesses quality attributes such
as : usability, efficiency, reliability, maintainability and reusability.
• These requirements constrain the design to meet specified levels of
quality.
• The following are some of the main categories of quality requirements.
 Response time
• For systems that process a lot of data or use a network extensively, you
should require that the system gives results or feedback to the user in a
certain minimum time.
• For example, you might write that a result must be calculated in less than
three seconds, or that feedback about the progress of a search must
appear within one second.
• However, that for hard real-time systems, response time requirements
should be considered to be functional – the system would not work unless
they are adhered to.
 Throughput
• For number-crunching programs that may take hours, or for servers that
continually respond to client requests, it is a good idea to specify
throughput, in terms of computations or transactions per minute.
 Resource usage
• For systems that use non-trivial amounts of such resources as memory
and network bandwidth, you should specify the maximum amount of
these resources that the system will consume.
• This allows others to plan hardware upgrades.
• For example, you could specify that no more than 50 MB of memory is to
be used by the system, and that the system must consume less than 10%
of the CPU’s time when run on a 1.8GHz machine under a certain
operating system.
 Reliability
• Reliability is measured as the average amount of time between failures or
the probability of a failure in a given period.
• It is a good idea to set strong but realistic targets for this. For example, you
might specify that a continuously running server must not suffer more
than one failure in six months period.
• It is necessary to define what you mean by a failure: normally it means
much more than just crashes; failures normally include any difficulties
users have getting their work done which are attributable to defects.
 Availability
• Availability measures the amount of time that a server is running and
available to respond to users.
• As with reliability, you should set a target for this. For example, you might
specify that a server must be available over 99% of the time, and that no
period of downtime may exceed 1 minute.
• Telecommunications systems have very rigorous availability criteria: for
example, you might specify that such a system must not be down more
than 10 minutes in its 20-year life-span.
 Recovery from failure.
• Requirements in this category constrain the allowed impact of a failure.
• If the hardware or software crashes, or the power fails, then the system
will be able to recover within a certain amount of time, and with a certain
minimal loss of data.
• For example, the requirements for a word processor might state: ‘the
system will allow users to continue their work after a failure with the loss
of no more than 20 words of typing or 20 formatting commands.’
• But the detailed procedure for recovery from failure is a functional
requirement.
 Allowances for maintainability and enhancement
• In order to ensure that the system can be adapted in the future, you
should describe changes that are anticipated for subsequent releases.
• This constrains design and improves quality without adding explicit new
functional requirements.
 Allowances for reusability.
• Similarly to the previous category, it is desirable in many cases to specify
that a certain percentage of the system, e.g. 40%, measured in terms of
lines of code, must be designed generically so that it can be reused.
Platform requirements
• This type of requirement constrains the environment and technology of
the system:
 Computing platform
• It is normally important to make it clear what hardware and operating
system the software must be able to work on.
• Such requirements specify the least powerful platforms and declare that it
must work on anything more recent or more powerful.
• For example, you might declare that certain software must run on any
computer operating under Mac OS X version 10.2 or MS-Windows 98 or
higher, with 128 MB of RAM or more, and 100 MB of free disk space.
 Technology to be used.
• While it is wise to give the designers as much flexibility as possible in
choosing how to implement the system, sometimes constraints must be
imposed.
• Common examples are to specify the programming language or database
system.
• Such requirements are normally stated to ensure that all systems in an
organization use the same technology – this reduces the need to train
people in different technologies.
• The company might have also spent considerable money on a certain
technology and wants to get the best value for that money.
Process requirements
• The final type of requirements constrains the project plan and
development methods:
 Development process (methodology) to be used.
• In order to ensure quality, some requirements documents specify that
certain processes be followed; for example, particular approaches to
testing.
• The details of the process should not be included in the requirements;
instead a reference should be made to other documents that describe the
process.
 Cost and delivery date.
• These are important constraints.
• However, they are usually not placed in the requirements document, but
are found in the contract for the system or are left to a separate project
plan document.
Requirements Elicitation
• It certainly seems simple enough—ask the
customer, the users, and others what the
objectives for the system or product are, what is
to be accomplished, how the system or product
fits into the needs of the business, and finally,
how the system or product is to be used on a dayto-day basis.
• But it isn’t simple—it’s very hard.
• A number of problems are identified that help us
understand why requirements elicitation is
difficult:
• Problems of scope
– The boundary of the system is ill-defined or the customers/
users specify unnecessary technical detail that may
confuse, rather than clarify, overall system objectives.
• Problems of understanding
– The customers/users are not completely sure of what is
needed, have a poor understanding of the capabilities and
limitations of their computing environment, don’t have a
full understanding of the problem domain, have trouble
communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify
requirements that conflict with the needs of other
customers/users, or specify requirements that are
ambiguous or untestable.
• Problems of volatility.
– The requirements change over time.
• To help overcome these problems, system engineers must approach the
requirements gathering activity in an organized manner.
• A set of detailed guidelines for requirements elicitation, which are
summarized in the following steps:
– Assess the business and technical feasibility for the proposed system.
– Identify the people who will help specify requirements and understand their
organizational bias.
– Define the technical environment (e.g., computing architecture, operating
– system, telecommunications needs) into which the system or product will be
– placed.
– Identify “domain constraints” (i.e., characteristics of the business environment
– specific to the application domain) that limit the functionality or performance
– of the system or product to be built.
– Define one or more requirements elicitation methods (e.g., interviews, focus
groups, team meetings).
– Solicit participation from many people so that requirements are defined from
different points of view; be sure to identify the rationale for each requirement
that is recorded.
– Identify ambiguous requirements as candidates for prototyping.
– Create usage scenarios to help customers/users better identify key
requirements.
• The work products produced as a consequence of the
requirements elicitation activity will vary depending on the
size of the system or product to be built.
• For most systems, the work products include
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who
participated in the requirements elicitation activity.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the
domain constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the
system or product under different operating conditions.
• Any prototypes developed to better define requirements.
• Each of these work products is reviewed by all people who
have participated in the requirements elicitation.
Requirement Elicitation (Gathering) Techniques (10 Marks)
1.
2.
3.
4.
Observation
Interviewing
Brainstorming
Prototyping
• The first gathering technique, observation, is used to obtain subtle
information that stakeholders may not think of telling you.
• The next three, interviewing, brainstorming and prototyping, are
complementary techniques for actively asking for the opinions and
knowledge of stakeholders as well as forcing the stakeholders to stretch
their minds.
• Users participate in all four of these techniques, therefore they feel
personally involved in the project.
• This sense of involvement means that they will more readily accept the
final system.
Observation
• You can read documents and discuss requirements extensively with users,
but often only the process of observing the users at work will bring to light
subtle details that you might otherwise miss.
• In its simplest form, observation means taking a notebook and
‘shadowing’ important potential users as they do their work, writing down
everything they do.
• You can also ask users to talk as they work, explaining what they are
doing.
• In another variation, you can videotape the session so that you can
analyze it in more detail later.
Interviewing
• Interviewing is a widely used technique.
• However, a well-conducted series of interviews can elicit much more
information than poorly planned ad-hoc interviews.
• Firstly, plan to have as many members of the software engineering team
• interview as many stakeholders as possible.
• Consider going beyond stakeholders, talking to users of competing
products, marketing personnel, and people involved with other systems
that may interact in any way with the proposed system.
• Spread out the interviews over time, and allow yourself several hours for
each interview, even if you do not expect to use that much time.
Brainstorming
• Brainstorming is an effective way to gather information from a group of
people.
• The general idea is that the group sits around a table and discusses some
topic with the goal of generating ideas.
• However, as with interviews, adding some structure to the brainstorming
process can help elicit a larger amount of information.
• One of the keys to success is arranging for the brainstorming session to be
led, or moderated, by somebody trained in the process.
Prototyping
• A prototype is a program that is rapidly implemented and contains only a
small part of the anticipated functionality of a complete system.
• Its purpose is to gather requirements by allowing software engineers to
obtain early feedback about their ideas.
• The simplest kind of prototype is a paper prototype of the user interface.
• This is a set of pictures of the system that are shown to customers and
users in sequence, to explain what would happen when the system runs.
• It can often be a very powerful tool for eliciting ideas and feedback, and
requires very little effort to create.
• Because paper prototypes are easy to create, they are ideal for parallel
development.
• In parallel development, several software engineers independently create
their own view of the system – the resulting prototypes are then
evaluated and the best features of each become part of the system’s
requirements.
• The most common type of prototype is a ‘mock-up’ of the system’s user
interface, created using a rapid prototyping language.
• Rapid prototyping languages allows you to create code very quickly in
order to display the important parts of a user interface.
• However, they have various weaknesses that limit their usefulness for
creating the final version of complex systems.
• The weaknesses include inefficiency, and limitations on your ability to
create robust and flexible designs.
Requirements Analysis and Negotiation
• Once requirements have been gathered, the work products
noted earlier form the basis for requirements analysis.
• Analysis categorizes requirements and organizes them into
related subsets; explores each requirement in relationship
to others; examines requirements for consistency,
omissions, and ambiguity; and ranks requirements based
on the needs of customers/users.
• As the requirements analysis activity commences, the
following questions are asked and answered:
• Is each requirement consistent with the overall objective for
the system/product?
• Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an addon feature that may not be essential to the objective of the
system?
• Is each requirement bounded and unambiguous(clear)?
• Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that
will house the system or product?
• Is each requirement testable, once implemented?
• It isn’t unusual for customers and users to ask for more
than can be achieved, given limited business resources.
• It also is relatively common for different customers or
users to propose conflicting requirements, arguing that
their version is “essential for our special needs.”
• The system engineer must reconcile these
conflicts through a process of negotiation.
• Customers, users and stakeholders are asked to
rank requirements and then discuss conflicts in
priority.
• Risks associated with each requirement are
identified and analyzed.
• Rough estimates of development effort are made
and used to assess the impact of each
requirement on project cost and delivery time.
• Using an iterative approach, requirements are
eliminated, combined, and/or modified so that
each party achieves some measure of
satisfaction.
Requirements Specification
• A specification can be a written document, a graphical model,
a formal mathematical model, a collection of usage scenarios,
a prototype, or any combination of these.
• The System Specification is the final work product produced by
the system and requirements engineer.
• It serves as the foundation for hardware engineering,
software engineering, database engineering, and human
engineering.
• It describes the function and performance of a computerbased system and the constraints that will govern its
development.
• The System Specification also describes the information (data
and control) that is input to and output from the system.
System Modeling
• It is important to evaluate the system’s
components in relationship to one another, to
determine how requirements fit into this
picture, and to assess the “aesthetics” of the
system as it has been formed.
Requirements Validation
• The work products produced as a consequence of requirements
engineering (a system specification and related information) are assessed
for quality during a validation step.
• Requirements validation examines the specification to ensure that all
system requirements have been stated unambiguously; that
inconsistencies, omissions, and errors have been detected and corrected;
and that the work products conform to the standards established for the
process, the project, and the product.
• The primary requirements validation mechanism is the formal technical
review(FTR).
• The review team includes system engineers, customers, users, and other
stakeholders who examine the system specification looking for errors in
content or interpretation, areas where clarification may be required,
missing information, inconsistencies (a major problem when large
products or systems are engineered), conflicting requirements, or
unrealistic (unachievable) requirements.
• Although the requirements validation review can be conducted in any
manner that results in the discovery of requirements errors, it is useful to
examine each requirement against a set of checklist questions.
• The following questions represent a small subset of those that might be
asked:
– Are requirements stated clearly? Can they be misinterpreted?
– Is the source (e.g., a person, a regulation, a document) of the
requirement identified? Has the final statement of the requirement
been examined by or against the original source?
– Is the requirement bounded in quantitative terms?
– What other requirements relate to this requirement? Are they clearly
noted via a cross-reference matrix or other mechanism?
– Does the requirement violate any domain constraints?
– Is the requirement testable? If so, can we specify tests (sometimes
called validation criteria) to exercise the requirement?
– Is the requirement traceable to any system model that has been
created?
– Is the requirement traceable to overall system/product objectives?
– Is the system specification structured in a way that leads to easy
understanding, easy reference, and easy translation into more
technical work products?
– Has an index for the specification been created?
– Have requirements associated with system performance, behavior,
and operational characteristics been clearly stated? What
requirements appear to be implicit?
• Checklist questions like these help ensure that the validation team has
done everything possible to conduct a thorough review of each
requirement.
Requirements Management
• Requirements management is a set of
activities that help the project team to
identify, control, and track requirements and
changes to requirements at any time as the
project proceeds.
• Many of these activities are identical to the
software
configuration
management
techniques
Design Workflow
System Design Concept- Cohesion &
Coupling
COHESION
• The cohesion principle is an extension of the divide and conquer principle
– divide and conquer simply says to divide things up into smaller chunks.
• Cohesion says to do it intelligently: i.e., divide things up, but keep things
together that belong together.
• A subsystem or module has high cohesion if it keeps together things that
are related to each other, and keeps out other things.
• This makes the system as a whole easier to understand and change.
• Listed below are several important types of cohesion that designers
should try to achieve.
• Table summarizes these types of cohesion, starting with the most
desirable.
Functional cohesion
• This is achieved when all the code that
computes a particular result is kept together and everything else is kept out
– i.e. when a module only performs a single
computation, and returns a result, without having
side-effects.
– Benefits to the system:
• Easier to understand
• More reusable
• Easier to replace
– Modules that update a database, create a new file
or interact with the user are not functionally
40
cohesive
Layer cohesion
• All the facilities for providing or accessing a set of related services are kept
together, and everything else is kept out
– The layers should form a hierarchy
• Higher layers can access services of lower layers,
• Lower layers do not access higher layers
– The set of procedures through which a layer provides its services is the
application programming interface (API)
– You can replace a layer without having any impact on the other layers
• You just replicate the API
41
Example of the use of layers
42
Communicational cohesion
• All the modules that access or manipulate
certain data are kept together (e.g. in the
same class) - and everything else is kept out
– A class would have good communicational
cohesion
• if all the system’s facilities for storing and manipulating
its data are contained in this class.
• if the class does not do anything other than manage its
data.
– Main advantage: When you need to make
changes to the data, you find all the code in one
place
43
Sequential cohesion
• Procedures, in which one procedure provides
input to the next, are kept together – and
everything else is kept out
– You should achieve sequential cohesion, only once
you have already achieved the preceding types of
cohesion.
44
Procedural cohesion
• Procedures that are used one after another
are kept together
– Even if one does not necessarily provide input to
the next.
– Weaker than sequential cohesion.
45
Temporal Cohesion
• Operations that are performed during the
same phase of the execution of the program
are kept together, and everything else is kept
out
– For example, placing together the code used
during system start-up or initialization.
– Weaker than procedural cohesion.
46
Utility cohesion
• When related utilities which cannot be
logically placed in other cohesive units are
kept together
– A utility is a procedure or class that has wide
applicability to many different subsystems and is
designed to be reusable.
– For example, the java.lang.Math class.
47
COUPLING
• Coupling occurs when there are interdependencies between one module
and another. Figure illustrates the concept of a tightly coupled and loosely
coupled system.
•Abstract examples of a tightly coupled system (left) and a loosely coupled
system (right).
• The boldness of the arrows indicates the strength of the coupling
•In general, the more tightly coupled a set of modules is, the harder it is to
understand and, hence, change the system.
• Two reasons for this are:
• ■ When interdependencies exist, changes in one place will require
changes somewhere else.
• Requiring changes to be made in more than one place is problematic
since it is time-consuming to find the different places that need changing,
and it is likely that errors will be made.
• ■ A network of interdependencies makes it hard to see at a glance how
some component works.
• Additionally, coupling implies that if you want to reuse one module, you
will also have to import those with which it is coupled.
• This is because the coupled components need each other in order to work
properly.
Content coupling:
• Occurs when one component surreptitiously
modifies data that is internal to another
component
– To reduce content coupling you should therefore
encapsulate all instance variables
• declare them private
• and provide get and set methods
– A worse form of content coupling occurs when
you directly modify an instance variable of an
instance variable
51
Common coupling
• Occurs whenever you use a global variable
– All the components using the global variable
become coupled to each other
– A weaker form of common coupling is when a
variable can be accessed by a subset of the
system’s classes
• e.g. a Java package
– Can be acceptable for creating global variables
that represent system-wide default values
52
Control coupling
• Occurs when one procedure calls another
using a ‘flag’ or ‘command’ that explicitly
controls what the second procedure does
– To make a change you have to change both the
calling and called method
– The use of polymorphic operations is normally the
best way to avoid control coupling
– One way to reduce the control coupling could be
to have a look-up table
• commands are then mapped to a method that should
be called when that command is issued
Example of control coupling
public routineX(String command)
{
if (command.equals("drawCircle")
{
drawCircle();
}
else
{
drawRectangle();
}
}
54
Stamp coupling:
• Occurs whenever one of your application
classes is declared as the type of a method
argument
– Since one class now uses the other, changing the
system becomes harder
• Reusing one class requires reusing the other
– Two ways to reduce stamp coupling,
• using an interface as the argument type
• passing simple variables
55
Example of stamp coupling
public class Emailer
{
public void sendEmail(Employee e, String text)
{...}
...
}
Using simple data types to avoid it:
public class Emailer
{
public void sendEmail(String name, String email, String text)
{...}
...
}
56
Example of stamp coupling
Using an interface to avoid it:
public interface Addressee
{
public abstract String getName();
public abstract String getEmail();
}
public class Employee implements Addressee {…}
public class Emailer
{
public void sendEmail(Addressee e, String text)
{...}
...
}
57
Data coupling
• Occurs whenever the types of method
arguments are either primitive or else simple
library classes
– The more arguments a method has, the higher the
coupling
• All methods that use the method must pass all the
arguments
– You should reduce coupling by not giving methods
unnecessary arguments
58
Routine call coupling
• Occurs when one routine (or method in an
object oriented system) calls another
– The routines are coupled because they depend on
each other’s behaviour
– Routine call coupling is always present in any
system.
– If you repetitively use a sequence of two or more
methods to compute something
• then you can reduce routine call coupling by writing a
single routine that encapsulates the sequence.
59
Type use coupling
• Occurs when a module uses a data type
defined in another module
– It occurs any time a class declares an instance
variable or a local variable as having another class
for its type.
– The consequence of type use coupling is that if
the type definition changes, then the users of the
type may have to change
– Always declare the type of a variable to be the
most general possible class or interface that
contains the required operations
60
Inclusion or import coupling
• Occurs when one component imports a package
– (as in Java)
• or when one component includes another
– (as in C++).
– The including or importing component is now exposed to
everything in the included or imported component.
– If the included/imported component changes something
or adds something.
• This may raises a conflict with something in the
includer, forcing the includer to change.
– An item in an imported component might have the same
name as something you have already defined.
61
External coupling
• When a module has a dependency on such
things as the operating system, shared
libraries or the hardware
– It is best to reduce the number of places in the
code where such dependencies exist.
62
ARCHITECTURAL STYLES
• The software that is built for computer-based systems exhibits one of
many architectural styles.
• Each style describes a system category that encompasses
– (1) a set of components (e.g., a database, computational modules)
that perform a function required by a system;
– (2) a set of connectors that enable “communication, coordination and
cooperation” among components;
– (3) constraints that define how components can be integrated to form
the system; and
– (4) semantic models that enable a designer to understand the overall
properties of a system by analyzing the known properties of its
constituent parts
Commonly used architectural patterns for software are as follows
Data-centered architectures
• A data store (e.g., a file or database) resides at the center of this
architecture and is accessed frequently by other components that update,
add, delete, or otherwise modify data within the store.
• Figure illustrates a typical data-centered style..
• Client software accesses a central repository.
• In some cases the data repository is passive. That is, client software
accesses the data independent of any changes to the data or the actions
of other client software.
• A variation on this approach transforms the repository into a “blackboard”
that sends notifications to client software when data of interest to the
client change.
• Data-centered architectures promote integrability. That is, existing
components can be changed and new client components can be added to
the architecture without concern about other clients (because the client
components operate independently).
• In addition, data can be passed among clients using the blackboard
mechanism (i.e., the blackboard component serves to coordinate the
transfer of information between clients).
• Client components independently execute processes.
Data-flow architectures.
• This architecture is applied when input data are to be transformed
through a series of computational or manipulative components into
output data.
• A pipe and filter pattern (Figure a) has a set of components, called filters,
connected by pipes that transmit data from one component to the next.
• Each filter works independently of those components upstream and
downstream, is designed to expect data input of a certain form, and
produces data output (to the next filter) of a specified form.
• However, the filter does not require knowledge of the working of its
neighboring filters.
• If the data flow degenerates into a single line of transforms, it is termed
batch sequential.
• This pattern (Figure b) accepts a batch of data and then applies a series of
sequential components (filters) to transform it.
Call and return architectures
• This architectural style enables a software designer (system architect) to
achieve a program structure that is relatively easy to modify and scale.
• A number of sub styles exist within this category:
• (1)Main program/subprogram architectures
– This classic program structure decomposes function into a control
hierarchy where a “main” program invokes a number of program
components, which in turn may invoke still other components.
– Figure illustrates an architecture of this type.
• (2)Remote procedure call architectures.
– The components of a main program/ subprogram architecture are
distributed across multiple computers on a network
Object-oriented architectures
• The components of a system encapsulate data and the operations that
must be applied to manipulate the data.
• Communication and coordination between components is accomplished
via message passing.
Layered architectures
• The basic structure of a layered architecture is illustrated in Figure.
• A number of different layers are defined, each accomplishing operations
that progressively become closer to the machine instruction set.
• At the outer layer, components service user interface operations.
• At the inner layer, components perform operating system interfacing.
• Intermediate layers provide utility services and application software
functions.
Identifying Subsystem
System:
 A system is logical entity having a set of
definable responsibilities or objectives and consisting
of h/w, s/w or both.

A system can have a specification which is
then implemented by a collection of components
Subsystem:
 A subsystem is a system that is part
of a larger system and which has a definite
interface.
 Java uses packages to implement
subsystems individual classes may also
implement particular low level subsystem.
 Aggregation are special association
that represent part whole relationships.
 The whole side of relationship is
called as aggregate of assembly.
A subsystem is illustrated in UML as a special
type of package with little upside down fork
symbol in a small protruding base at the top
left.
A subsystem is drawn with three
compartments :
The operation shown towards the top left
corner

The specification elements (normally a
use case diagram) shown towards the
bottom left corner

Realization elements (typically a class
or interaction diagram on the right)
The mapping between realization elements and
the other elements can be shown using dashed
arrows with open triangles as arrowheads.