مهندسی فناوری اطلاعات

مهندسی فناوری اطلاعات

فناوری اطلاعات و کامپیوتر


Tools for Understanding the Behavior of Telecommunication Systems
Andr´e Marburger
Aachen University of Technology
Department of Computer Science III
Ahornstraße 55, 52074 Aachen, Germany
Bernhard Westfechtel
Aachen University of Technology
Department of Computer Science III
Ahornstraße 55, 52074 Aachen, Germany
Many methods and tools for the reengineering of software
systems have been developed so far. However, the
domain-specific requirements of telecommunication systems
have not been addressed sufficiently. These systems
are designed in a process- rather than in a data-centered
way. Furthermore, analyzing and visualizing dynamic behavior
is a key to system understanding. In this paper, we
report on tools for the reengineering of telecommunication
systems which we have developed in close cooperation with
an industrial partner. These tools are based on a variety of
techniques for understanding behavior such as visualization
of link chains, recovery of state diagrams from the source
code, and visualization of traces by different kinds of diagrams.
Tool support has been developed step by step in response
to the requirements and questions stated by telecommunication
experts at Ericsson Eurolab Germany.
1. Introduction
Reengineering of large and complex software systems
has proved a difficult task. According to the “horseshoe
model of reengineering” [4, 10], reengineering is divided
into three phases. Reverse engineering is concerned with
step-wise abstraction from the source code and system comprehension.
In the restructuring phase, changes are performed
on different levels of abstraction. Finally, forward
engineering introduces new parts of the system (from the
requirements down to the source code level).
For reengineering, many methods and tools have been
developed. To a large extent, however, previous work has
been data-centered since it focuses on structuring the data
maintained by an application. In particular, numerous approaches
have addressed the migration of legacy business
applications — written, e.g., in COBOL — to an objectbased
or object-oriented architecture [5, 15, 23]. This task
requires the grouping of data and functions into classes
with corresponding attributes and methods. Another stream
of research has dealt with programming languages such as
C++ and Java which already provide language support for
object-oriented programming [17].
Reengineering of process-centered applications has been
addressed less extensively so far [25]. For example, a
telecommunication system is composed of a set of distributed
communicating processes which are instantiated
dynamically for handling calls requested by its users. Such
a system is designed in terms of services provided by entities
which communicate according to protocols. Understanding
a telecommunication system requires the recovery
of this conceptual world from the actual source code and
other sources of information.
The E-CARES1 research cooperation between Ericsson
Eurolab Deutschland GmbH (EED) and Department of
Computer Science III, Aachen University of Technology,
has been established to develop methods, concepts, and
tools for the reengineering of complex legacy telecommunication
systems. E-CARES has been driven strongly by
the requirements of software engineers who are involved in
the design and implementation of GSM networks for mobile
communication. The subject of study is Ericsson’s Mobileservice
Switching Center (MSC) for GSM networks called
AXE10. The AXE10 software system comprises approximately
10 million lines of code spread over about 1,000
executable units, and has an estimated lifetime of about 40
years. Thus, there is an urgend need for tool support to improve
program evolution and maintenance.
In E-CARES, a prototypical environment — called ECARES
prototype [14] — is being developed which addresses
the reengineering of telecommunication systems.
So far, tool support covers only reverse engineering, i.e.,
the first phase of reengineering. While structural analysis
is covered as well, we put strong emphasis on behavioral
analysis since the structure alone is not very expressive in
the case of a telecommunication system.
1Ericsson Communication ARchitecture for Embedded Systems [13]
Base Transceiver System
Base Station Controller
Switching Center
Mobile Station
other networks
Figure 1. Simplified sketch of a GSM network
The rest of this paper is structured as follows: Section 2
motivates our research and explains its background. Section
3 gives an overview of the E-CARES prototype. Section
4 briefly describes structural analysis. Section 5, the
core part of this paper, presents a variety of techniques
which support the understanding of behavior. Section 6
introduces metrics — for both structure and behavior —
which further improve the understanding of telecommunication
systems. Section 7 discusses related work, and Section
8 concludes this paper.
2. Background
The mobile-service switching centers are the heart of a
GSM network (Figure 1). An MSC provides the services
a person can request by using a mobile phone, e.g., a simple
phone call, a phone conference, or a data call, as well
as additional infrastructure like authentication. Each MSC
is supported by several Base Station Controllers (BSC),
each of which controls a set of Base Station Transceivers
(BTS). The interconnection of MSCs and the connection
to other networks (e.g., public switched telecommunication
networks) is provided by gateway MSCs (GMSC). In
fact, the MSC is the most complex part of a GSM network.
An MSC consists of a mixture of hardware (e.g., switching
boards) and software units. In our research we focus on the
software part of this embedded system.
Figure 2 illustrates how a mobile originating call is handled
in the MSC. The figure displays logical rather than
physical components according to the GSM standard; different
logical components may be mapped onto the same
physical component. The mobile originating MSC (MSCMO)
for the A side (1) passes an initial address message
(IAM) to a GMSC which (2) sends a request for routing information
to the home location register (HLR). The HLR
looks up the mobile terminating MSC (MSC-MTE) and (3)
sends a request for the roaming number. The MSC-MTE
Figure 2. Mobile originating call
Figure 3. System architecture
assigns a roaming number to be used for addressing during
the call and stores it in its visitor location register (VLR, not
shown). Then, it (4) passes the roaming number back to the
HLR which (5) sends the requested routing information to
the GMSC. After that, the GMSC (6) sends a call request to
the MSC-MTE. The MSC (7) returns an address complete
message (ACM) which (8) is forwarded to the MSC-MO.
Now, user data may be transferred between A and B.
Ericsson’s implementation of the MSC is called AXE10,
whose system architecture is shown in Figure 3. Each MSC
has a central processor which is connected to a set of regional
processors for controlling various hardware devices
by sensors and actors. The core of the processing is performed
on the central processor. The AXE10 software is
composed of blocks which constitute units of functionality
and communicate by exchanging signals (see below).
On each processor, a runtime system (called APZ) is installed
which controls the execution of all blocks executing
on this processor. An event raised by some hardware device
is passed from the regional processor to the block handling
this event on the central processor. In response to the event,
an effect may be triggered on another hardware device.
The executable units of the AXE10 software system are
implemented in Ericsson’s in-house programming language
PLEX (Programming Language for EXchanges), which was
developed in about 1970 and has been extended since then.
PLEX is an asynchronous concurrent real-time language
designed for programming of telecommunication systems.
The programming language has a signaling paradigm as the
top execution level. That is, only events can trigger code execution.
Events are programmed as signals.
A PLEX program is composed of a set of blocks which
are compiled independently. Each block consists of a number
of sectors for data declarations, program statements, etc.
(see Figure 8, which will be explained more thoroughly in
Section 5). Although PLEX does not support any further
structuring within these sectors, we have identified some additional
structuring through coding conventions in the program
sector. At the beginning of the program sector all
signal reception statements (signal entries) of a block are
coded. After these signal entry points, a number of labeled
statement sequences follows. The bottom part of the program
sector consists of subroutines.
The control flow inside a program sector is provided by
goto and call statements. The goto statement is used
to jump to a label of a labeled statement sequence. Subroutines
are accessed by means of call statements. Both
goto and call statements are parameter-less. That is,
they affect only the control flow, but not the data flow.
Inter-block communication and data transport is provided
by different kinds of signals. As every block has data
encapsulation, signals are able to carry data. Therefore, signals
may affect both the control flow and the data flow.
At runtime, every block can create several instances
(processes). This again is not a feature of the PLEX programming
language but achieved by means of implementation
tricks and coding conventions. Therefore, these instances
are managed by the block and not by the runtime
3. E-CARES prototype
In the E-CARES project, we design and implement tools
for reengineering of telecommunication systems and apply
them to the AXE10 system developed at Ericsson. The basic
architecture of the E-CARES prototype is outlined in
Figure 4. The solid parts indicate the current state of realization,
the dashed parts refer to further extensions.
Below, it is crucial to distinguish between the following
kinds of analysis: Structural analysis refers to the static system
structure, while behavioral analysis is concerned with
its dynamic behavior. Thus, the attributes “structural” and
“behavioral” denote the outputs of analysis. In contrast,
static analysis denotes any analysis which can be performed
on the source code, while dynamic analysis requires information
from program execution. Thus, “static” and “dynamic”
refer to the inputs of analysis. In particular, behavior
can be analyzed both statically and dynamically.
We obtained three sources of information for the static
analysis of the structure of a PLEX system. The first one
is the source code of the system. It is considered to be the
Figure 4. Prototype architecture
core information as well as the most reliable one. Through
code analysis (parsing) a number of structure documents is
generated from the source code, one for each block. These
structure documents form a kind of textual graph description.
The second and the third source of information are
miscellaneous documents (e.g., product hierarchy description)
and the system documentation. As far as the information
from these sources is computer processable, we use
parsers and scripts to extract additional information, which
is stored in structure documents, as well.
The static analysis tool processes the graph descriptions
for individual blocks and creates corresponding subgraphs
of the structure graph representing the overall application.
The subgraphs are connected by performing global analyses
in order to bind signal send statements to signal entry
points. Moreover, the subgraphs for each block are reduced
by performing simplifying graph transformations [13]. The
static analysis tool also creates views of the system at different
levels of abstraction. In addition to structure, static
analysis is concerned with behavior (e.g., extraction of state
machines or of potential link chains from the source code).
There are two possibilities to obtain dynamic information:
using an emulator or querying a running AXE10. In
both cases, the result is a list of events plus additional information
in a temporal order. Such a list constitutes a trace
which is fed into the dynamic analysis tool. Interleaved with
trace simulation, dynamic analysis creates a graph of interconnected
block instances that is connected to the static
structure graph. This helps telecommunication experts to
identify components of a system that take part in a certain
traffic case. At the user interface, traces are visualized by
collaboration and sequence diagrams.
Both the static and the dynamic analysis tool calculate
metrics which were designed to improve the understanding
of both structure and behavior. These metrics are visualized
e.g. in the underlying structure graph (see Section 6).
The dashed parts of Figure 4 represent planned extensions
of the current prototype. The re-design tool will be
used to map structure graph elements to elements of a modeling
language (e.g., ROOM [20] or SDL [8]). This will
result in an architecture graph that can be used to perform
architectural changes to the AXE10 system. The code generator
will generate PLEX code according to changes in the
structure graph and/or the architecture graph. The wrapper
generator will enable reuse of existing parts of the AXE10
system written in PLEX in a future switching system that is
written in a different programming language, e.g., C++.
To reduce the effort of implementing the E-CARES prototype,
we make extensive use of generators and reusable
frameworks [14]. Scanners and parsers are generated with
the help of JLex and jay, respectively. Graph algorithms are
written in PROGRES [19], a specification language based
on programmed graph transformations. From the specification,
code is generated which constitutes the application
logic of the E-CARES prototype. The user interface is implemented
with the help of UPGRADE [1], a framework for
building interactive tools for visual languages.
4. Structural analysis
The static structure of a PLEX program is represented
internally by a structure graph, a small (and simplified) example
of which is shown in Figure 52. In the example,
there is a subsystem which contains two blocks A and B.
The subgraphs for these blocks are created by the PLEX
parser. The subgraph for a block — the block structure
graph—contains nodes for signal entry points, labels, (contiguous)
statement sequences, subroutines, exit statements,
etc. Thus, the block structure graph shows which signals
may be processed by the block, which statement sequences
are executed to process these signals, which subroutines are
used for processing, etc. In addition, the block structure
graph initially contains nodes representing outgoing signals.
Subsequently, a global analysis is carried out to bind
outgoing signals to receiving blocks based on name identity.
In our example, a signal H is sent in the statement sequence
X of block A. This signal is bound to the entry point of block
B. From the signal edges between statement sequences and
signal entry points, more coarse-grained communication
edges may be derived (between blocks and eventually between
Externally (at the user interface), the structure graph is
represented by multiple views [13]. The product hierarchy
is displayed in a tree view. Furthermore, there is a variety of
graphical views which display the structure graph at different
levels of abstraction (internals of a block, block communication
within a subsystem, communication between subsystems).
For example, Figure 13 shows block communications
within a subsystem of AXE10 (see Section 6 for fur-
2For the time being, please ignore all graph elements for link chains
(lc), which will be explained in Section 5.
Figure 5. Cutout
of a structure graph
ther explanations). The user may select among a set of different,
customizable layout algorithms to arrange graphical
representations in a meaningful way. He may also collapse
and expand sets of nodes to adjust the level of detail. Graph
elements representing code fragments are connected to the
respective source code regions, which may be displayed on
demand in text views.
5. Behavioral analysis
5.1. Motivation
As stated in Section 1, we found that the static system
structure is not very expressive in the case of telecommunication
systems. These highly dynamic, flexible, and reactive
systems handle thousands of different calls at the same
time. The numerous services provided by a telecommunication
system are realized by re-combining and re-connecting
sets of small (stand alone) processes, block instances in our
case, at runtime. Each of these block instances realizes a
certain kind of (internal) mini-service. Some of the blocks
can even create instances for different mini-services dependent
on the role they have to play in a certain scenario.
Therefore, structural analysis as described in Section 4
is not sufficient to understand telecommunication systems.
For example, the structure graph does not contain any information
on how many instances of a single block are used to
set up a simple phone call. In Figure 6, a so-called link chain
for the GSM-layer 3 part of a simple mobile originating call
is sketched. Link chains describe how block instances are
combined at runtime to realize a certain service. Each node
represents a block instance. An edge between two nodes indicates
signal interchange between these blocks. Each link
chain consists of a main part (directed edges) and side-links
for supplementary services (authentication, charging, etc.).
The directed edges between elements of the main link chain
indicate its establishment from left to right; communication
is bidirectional in all cases. In correspondence to Figure
Call Control A-Subscriber
Traffic Coordinator A-Subscriber
Message Handler Call Control
Cross Phase Protocol Handler
Call Data and Charging Control
Transport Protocol Handler Incoming
Transport Protocol Handler Outgoing
Routing Interrogation Gateway
Roaming Routing Gateway
Call Control B-Subscriber
Traffic Coordinator B-Subscriber
Database Access Part
Figure 6. Simplified link chain for mobile originating
call at GSMlayer
2, the link chain in Figure 6 is divided into the three parts
This simple example shows that there are, e.g., three instances
of the charging access (CDCC), two message handler
instances (MHCC), and two instances of the CPPH protocol
handler block needed to setup a mobile originating
call. This kind of behavioral information is very important
to telecommunication engineers. Sections 5.2 and 5.4 describe
how information on link chains can be derived via
static and dynamic analysis, respectively.
Furthermore, each block in Figure 6 implements at least
one state machine. State machines are a common modeling
means in the design of telecommunication systems. Therefore,
telecommunication experts are interested in having a
good knowledge about the state machines implemented in
a block and their operation at runtime. Extraction of state
machines from source code is discussed in Section 5.3.
5.2. Static link chain analysis
In case of the AXE10, link chains can be obtained from
static analysis by making use of an error recovery mechanism
implemented in the system. The mechanism allows to
kill processes specific to an erroneous link chain if normal
error recovery fails. Each block instance that is the initiator
of a new link chain first notifies the Link Chain Manager
(LCM) of the APZ via an lc start message (Figure 7). The
LCM creates a new Link Chain Identifier (LID), stores it in
the Link Chain Register, and returns it to the initiating block
instance. Now the LID will be implicitly attached to every
signal the initiating block instance sends to any other block
instance. If another block instance is requested, it notifies
its participation in a link chain by sending an lc part message
to the LCM which in turn will respond by sending an
acknowledgment containing the currently valid LID from
the Link Chain Register. The LID will now be implicitly
attached to the second block’s signals as well etc.
The lc * messages to the platform system are represented
by corresponding PLEX statements in the source code.
Figure 7. Link chain handling
Thus, these statements are detected and inserted into the
structure graph during structural analysis (see Figure 5).
The static link chain analysis searches for the occurrence
of an lc start statement in a given block’s structure graph
and marks the surrounding statement sequence. All signals
sent after the link chain initiation notification by this
statement sequence do transmit an LID3. Thus, these signals
are traversed to the receiving blocks. Next, the block
structure graph of each receiving block is traversed starting
from a signal entry point which one of the signal edges is
connected to. If an lc part statement is reachable from this
signal entry, an lc next block edge is inserted into the structure
graph between sending and receiving block.
In Figure 5, block A contains an lc start statement in
statement sequence X. Furthermore, signal H triggers the
execution of statement sequence Y in block B which contains
an lc part statement. As a result, a new edge of type
lc next block is inserted into the structure graph to indicate
that A and B can take part in the same link chain.
After having performed static link chain analysis on the
structure graph, it is possible to visualize which blocks potentially
take part in the same link chain and which block
triggers the participation of which other blocks. Indeed,
if the static link chain analysis is performed for the whole
structure graph, the result is the union of all link chains that
can occur at runtime. Nevertheless, this information is very
useful as most link chains appear to be constructed from
smaller, invariant link chains. Additionally, the scope of a
static link chain analysis can be limited by selecting a starting
block. In this case, only blocks are considered that are
reachable from the starting block via a path of signals. Here,
link chain analysis also accepts lc part statements as initiators
of a ‘new’ link chain because an intermediate block of
a real link chain might have been selected as starting point.
Furthermore, certain classes of telecommunication services
3To be precise, the lc start statement must not be part of a conditional
statement to make sure that subsequently sent signals do transmit an LID.
Otherwise, only signals in the same conditional context do so.
(e.g., voice calls) always have a kind of basic common link
chain. Smaller chains representing different supplementary
services are just linked in on demand. In combination with
system traces (see Section 5.5), it is possible to identify the
basic common link chains.
5.3. State machine extraction
The information extracted from the source code and
other sources of information, its representation, and its visualization
have to meet the demands of both the reengineer
and the system experts involved. In particular, telecommunication
systems are often planned and modeled using
state machines. That is, system experts think in terms of
state machines and protocols. Thus, the design process is
process- and behavior-centered rather than data-centered,
and blocks are just implementations of one or more state
machines. Though PLEX does not provide any language
elements for state machine implementation, the knowledge
of some (informal) design rules at Ericsson and additional
manual analysis of a couple of PLEX blocks allowed to develop
an algorithm to detect state machines in and extract
them from a block’s source code or structure graph, respectively.
The example code in Figure 8 represents the main patterns
used to implement state machines in PLEX. Every
block contains declarations of a stored (DS flag) data record
(BlockTRecord), a file to store several of these records, and
a pointer (BlockTPointer) to the record currently used in execution.
Each of these records represents a block instance.
A block implements a state machine if its stored record contains
a symbol variable of a string-valued enumeration type
whose name contains the substring STATE. Additionally, the
set of possible values of this state variable must enclose the
values IDLE and SEIZED. Furthermore, each signal entry
(ENTER .. signal name

) is immediately followed by a case
statement whose condition queries the current value of the
state variable. Each branch of this case statement triggers
different executions in the block (instance). Accordingly,
a state change is represented by an assignment to the state
variable. A design rule determines that a block must change
its state at most once per execution cycle. No state change
corresponds to a feedback loop in the underlying state machine.
Furthermore, after a state change and a possibly subsequent
signal sending statement, a block has to terminate
immediately by means of an EXIT statement.
Hence, using this information we can conclude from
the example in Figure 8 that block T owns a state variable
named STATE. This state variable can have – among others
– the values IDLE, SEIZED, SETUP, and DISC. When receiving
(consuming) SignalA in states IDLE or SEIZED, the
block will change to state SETUP and send SignalB. This results
in the lower three states and two transitions on the right
! Declare Sector !
RECORD BlockTRecord;
POINTER BlockTPointer(BlockTRecord);
! Program Sector !
! Begin Interface !
ENTER SignalA WITH SignalDataA;
GOTO SequenceY;
GOTO UnexpectedState;
ENTER SignalC WITH SignalDataC;
GOTO SequenceZ;
GOTO UnexpectedState;
! End Interface !
BlockTPointer:STATE = SETUP;
SEND SignalB WITH SomeData;
BlockTPointer:STATE = IDLE;
SEND SignalD WITH AgainSomeData;
Figure 8. Example code with relevant statements
for state machine extraction
side of Figure 9. That is, a cut-out of the block’s state machine
has been extracted. The rest of the state machine can
be extracted stepwise by analyzing the source code for each
signal entry as originator again and again. But compared
to a graph-based algorithm this procedure is inefficient for
large systems like the AXE10.
The graph-based state machine extraction algorithm traverses
a block’s structure graph trying to find a path from
a signal entry to a statement sequence that contains an assignment
to the state variable. In each run, the starting
states from the conditional clauses of the case statement and
the name of the incoming signal are stored. If a state assignment
is found, a state transition from the starting state
to the new state is inserted into the block’s state diagram.
The state transition is annotated with the incoming and the
outgoing signal. Additional information that is necessary
Figure 9. State machine extraction on structure
for the state machine extraction and that is not represented
by elements of the structure graph (e.g., conditional statements)
is stored in attributes of nodes and edges. Therefore,
all information that is needed for the extraction is obtained
in a single run of the PLEX parser.
In the sample graph of Figure 9 corresponding to the
source code in Figure 8, the transition from DISC to IDLE
can be obtained by starting with signal entry C. The conditions
for the branches of the subsequent case statement are
stored in the corresponding GOTO edges. On state DISC,
the execution of block T is continued at statement sequence
Z which modifies the state variable STATE, sends signal SignalD,
and terminates its execution.
The result of the state machine extraction is a state machine
of a block that might be too large. That is, it may
contain too many transitions. A reason for this anomaly is
given by nested if-clauses that query the current value of
different variables. At runtime only a small amount of all
possible pairs of values of these variables might be valid.
That is, only a subset of all possible execution paths through
this part of the source code might be possible in reality. The
identification of those state transitions that are valid is possible
in combination with trace information (see Section 6).
Another problem arises from the fact that blocks can
have several state machines inside – one for every miniservice
they implement. The algorithm is designed to extract
all state machines in parallel in a single pass.
5.4. Tracing
As stated in Section 3, there are two possibilities to obtain
dynamic information: using an emulator or querying a
running AXE10. In the latter case, the complexity of the
information traced has to be reduced to avoid that the system
gets into timing problems and becomes instable. Besides
error handling, tracing jobs have the highest priority
Figure 10. Obtaining dynamic information
in a running AXE10. Therefore, intense tracing can cause
abnormal behavior, e.g., through an increased number of
missed time constraints and the resulting system recovery
actions. Furthermore, tracing an AXE10 that is in normal
operation – handling thousands of calls at the same time –
results in trace files containing information on all of these
calls. This huge amount of information makes it difficult to
focus on a special call scenario, which is one of the goals of
tracing. If real-time issues are not regarded, there is no need
to query a running switching system. Consequently, we decided
to use the AXE10 emulator. However, the procedure
described below and the dynamic analysis tool are the same
for both sources of dynamic information.
First, the tracing facility of the emulator is configured.
The configuration determines which information (e.g., signal
interchange, data access) is to be captured in a trace
file and which parts of the system should be observed (e.g.,
several blocks in a certain subsystem). Currently, we are interested
in the following information: signals, sending and
receiving block (instance) of a signal, data transferred with
a signal, signal priority, and assignments to certain (state)
variables. After the configuration has finished, the running
emulator starts to capture all actions whose tracing has been
switched on (Figure 10). Now the testing equipment can be
used to set up a call scenario of interest, e.g., a mobile originating
call, and trigger the execution of telecommunication
services implemented in the AXE10.
The dynamic analysis tool and the associated trace file
parser read a selected trace file stepwise – action by action –
on demand. Every action is analyzed to identify the participating
entities (block instances, signals, etc.) of the instance
graph. The instance graph is then modified accordingly –
new elements are inserted and existing ones are updated.
Some modifications are also propagated into the static structure
graph. For example, every block instance is connected
Figure 11. Example of a collaboration diagram
to its corresponding block in the structure graph and the activation
of a block instance results in the activation of the
corresponding block.
During their daily work, telecommunication experts
need different views on the traffic cases they analyze.
Sometimes they just need a complete overview, sometimes
they focus on the inter-work of two block instances, and
sometimes the development of a call over time is their main
interest. Therefore, dynamic analysis provides three different
working modes: In step mode, the dynamic analysis
process is interactive. That is, the reengineer triggers the
analysis of each action in the selected trace file manually.
In run mode, the analysis tool processes the whole trace in
one run. This mode has been implemented to create complete
diagrams for re-documentation purposes. In animation
mode, the actions in a trace file are processed successively
in adjustable time intervals. The animation mode is
used to produce a slow motion replay of the actions that
took place in the systems software with respect to a certain
call scenario. For convenience, it is possible to switch between
the three working modes at any time.
All changes to the instance graph are directly visualized
in the dynamic analysis tool. Here, a reengineer is able to
refine and adjust the amount of information displayed by
means of a complex graph filter interactively. Furthermore,
he can choose between two kinds of diagrams that are commonly
used in the telecommunications domain: collaboration
diagrams and sequence diagrams similar to those provided
in the UML [2]. Collaboration diagrams can be used
in all three working modes of the analysis tool whereas sequence
diagrams are mainly used for re-documentation purposes.
For example, the collaboration diagram in Figure 11
and the sequence diagram in Figure 12 show the same trace
at the same stage. The different grey scales of the block
instances in Figure 11 illustrate that the block instances belong
to different subsystems.
The dynamic analysis tool has proved its value for system
analysis and system understanding in several tests and
discussions with the expert group from Ericsson supporting
Figure 12. Example of a sequence diagram
our research. However, in complex traces, huge amounts
of information are obtained from the emulator. As a result,
numerous elements are inserted into the instance graph that
have to be visualized to the user at once. In step mode and
even worse in animation mode, the user often gets confused
by the quantity of information after some time and might
even lose his track. There are two complementing possibilities
to support the user in understanding complex call
scenarios: limiting the observation scope of a trace and extending
the visualization with aging.
The limitation of the observation scope is necessary anyhow
to suppress noise in traces that results from periodic
jobs like access statistics in order to focus on special aspects.
Limitation means that observation is only activated
for selected blocks, signals, and variables of a traced system
in the emulator configuration. All other blocks etc. are ignored;
e.g., tracing could be limited to a certain subsystem.
But the block instances that take part in a certain call scenario
are always spread over various parts of the AXE10.
Hence, there are e.g. signals coming from the ignored parts
to observed blocks and vice versa. This leads to missing
links (signals) in the control flow of a trace, in the instance
graph, and in the diagrams produced by the dynamic analysis
tool. Therefore, a heuristic has been implemented in the
dynamic analysis tool that inserts synthetic signals during
trace analysis to keep traces connected. For example, the
heuristic marks signals sent to unobserved block instances
(out signal action), tracks the following signal actions for
a corresponding in signal action, and inserts an appropriate
synthetic incoming signal if it is missing4. For this purpose,
the dump of the emulator configuration that corresponds to
the current trace file is used to extract information on observed
entities. This is necessary to keep the diagrams correct.
Similarly, if another block is activated out of turn after
a signal has been sent to the ignored part of a system, there
4For each signal a pair of signal actions must be captured for a trace
file to be correct – an outgoing signal action at the sending block instance
and an incoming signal action at the receiving block instance. But, signal
actions are only captured for observed blocks.
must have been communication in the ignored part which
has not been captured. This circumstance can also be represented
by an appropriate synthetic signal during dynamic
analysis that summarizes this unknown communication.
In addition, the user is supported during trace analysis
through the aging of the representation elements in the visualization
of the instance graph. Consider a collaboration
diagram view, which represents the current state of a call’s
link chain. Some elements in this diagram remain inactive
while others participate continuously in the current part of
the trace. But this difference in the amount of participation
is not noticed easily in complex traces. Therefore, all
elements in the collaboration diagram which have not participated
recently in a current trace are faded out continuously.
If an element participates again, it is re-displayed
immediately. This procedure guarantees that the visualization
focuses on elements that determine the current behavior.
Keeping in mind that a call link chain develops over
time and that it creates temporary side links that are never
released explicitly for efficiency reasons, visualization aging
is a good means to analyze the evolution of a call over
5.5. Combining analyses
So far, the direct analysis of a system’s runtime behavior
has been addressed. But there are additional applications
for a combination of analyses. In Section 5.2 we have
mentioned that link chains for a certain class of calls (e.g.,
voice calls) have a common basic link chain that is extended
by side links representing different supplementary services
(e.g., charging). Traces can be used to identify basic link
chains and supplementary side links. The procedure is similar
to feature analysis as described in [7].
Always, several traces of the system are needed. To identify
the basic link chain of a class of calls, a number of traces
of different voice calls is needed. All these traces are now
processed by the dynamic analysis tool to produce corresponding
instance graphs. Next, the logical and operation
over all instance graphs is used to create an instance graph
that represents the intersection of all instance graphs that
result from trace analysis. This intersection graph corresponds
to the common basic link chain of all these traces.
To find out whether a side link inherently belongs to a
given type of call (e.g., a mobile originating call), additional
traces are needed that belong to other types of calls. Now,
all elements that are part of the other calls can be subtracted
from the instance graph of the first trace which results in a
set of elements that inherently belong to this kind of call.
The state machines statically extracted from source code
can be reused in the dynamic analysis of a systems runtime
behavior. Remember that state changes were captured in
trace files as well. In combination with a trace it is possible
Figure 13. Static communication weights
Figure 14. Dynamic communication weights
to animate the state machines of a marked set of blocks and
visualize them to the telecommunication expert.
6. Metrics
As presented so far, the E-CARES prototype provides
qualitative information on the structure and behavior of a
telecommunication system. In addition, telecommunication
experts are interested in quantitative information. The metrics
introduced in this section further improve the understanding
of a telecommunication system. Usually, metrics
are used for assessment (e.g., of the complexity of a system),
but so far we have not used them for this purpose.
Metrics are used to assign weights to graph elements.
These weights are defined with the help of both static and
dynamic information. They are attached to both structural
and behavioral graphs. At the user interface, weights are visualized
with the help of different representation attributes,
e.g., colors, size of boxes, or thickness of edges.
As an example, Figure 13 shows a view on the structure
graph which displays communications at the block level.
Static weights are assigned to communication edges based
on the number of types of signals sent from the source to
the destination. Colors and thickness of edges are used to
represent communication weights. The thick lines at the
center of the diagram indicate where the main traffic occurs.
Telecommunication experts at Ericsson considered
this information useful to distinguish “communication highways”
from “secondary roads”. Similarly, weights may be
attached to blocks based on the code size so that is easier
to understand where the main functionality is implemented
(not shown in the figure).
Static weights provide general information on potential
executions. However, the telecommunication expert may
be interested more specifically in what happens in a specific
trace (or a set of traces). To this end, we offer dynamic
weights. For example, each communication edge is
weighted by the number of signals sent along this edge in
a specific trace. Again, we may display these weights in
the structure graph. By comparing Figure 14 to Figure 13,
the user may recognize the specific behavior in a certain
trace. It is also possible to hide all elements which do not
participate at all in the trace under study. In this way, the
user may compare expected and actual behavior. Alternatively,
weights may be displayed in a collaboration diagram,
which provides a more detailed view on the execution since
it shows individual block instances.
As a final example, let us briefly discuss the assignment
of weights to elements of state machines. In Subsection 5.3,
we mentioned that static analysis may produce a state diagram
which is too large. To detect potentially dead elements,
state transitions are weighted according to the number
of occurrences in some trace (or in a set of traces). State
transitions with weight 0 may be obsolete.
7. Related work
The E-CARES prototype is a reengineering environment
designed for telecommunication systems. In particular,
it is based on domain-specific architectural concepts.
A telecommunication system is modeled as a set of active
components which communicate by sending and receiving
signals. Thus, modeling is process-centered. Since the
static system structure is not very expressive, analysis of
behavior plays a crucial role in E-CARES.
In contrast, many other reengineering tools such as e.g.
Rigi [16] or KOGGE [6] primarily focus on the static system
structure. Moreover, they are typically data-centered;
consider e.g. tools for the reengineering of COBOL programs
as described in [5, 15, 23]. Here, recovery of units of
data abstraction and migration to an object-oriented software
architecture play a crucial role [3]. More recently,
reengineering has also been studied for object-oriented programming
languages such as C++ and Java. E.g., TogetherJ
or Fujaba [17] generate class diagrams from source code.
Reengineering of telecommunication systems follows
different goals. Telecommunication systems are designed
in terms of layers, planes, services, protocols, etc. Behavior
is described with the help of state machines, message
sequence charts, link chains, etc. Thus, reengineering tools
are required to provide views on the system which closely
correspond to system descriptions given in standards, e.g.,
GSM. Telecommunication experts require views on the system
which match their conceptual abstractions.
In this paper, we focus on tools and techniques for behavioral
analysis offered by the E-CARES prototype. Below,
we compare these to other approaches.
In the literature, a lot of work is described on the extraction
of dynamic information from object-oriented systems.
The motivation for the need of dynamic information is quite
similar to ours: In object-oriented systems the runtime behavior
of a system is neither predictable nor understandable
by just performing different kinds of static analysis on the
system’s source code. Source code analysis does not provide
enough information to understand a software system
completely because there are components and relations that
only exist during its runtime.
There are different methods described how to extract or
gather dynamic information. In the majority of these methods,
the code of the target system is instrumented so that a
trace is produced of the components executed in each test
case. The level of instrumentation ranges from very low
level instrumentation where the components of a trace are
branches in the target system control flow [25] to the instrumentation
of class or method entry and exit points [22]
or inter-process messages [12, 24], respectively. Low level
instrumentation of a production system brings with it a significant
performance penalty since trace information is generated
each time the system passes through an conditional
statement like if, switch, or any other decision points. In
general, for a large real-time system like the AXE10 switching
system low level instrumentation would be too difficult.
In particular, if we ran a low level instrumented system, we
would experience severe timing problems within the system.
This would result in unusable traces.
Another approach that can be found nowadays is the utilization
of debugger and profiler logs to gather dynamic information
[7, 9, 21]. In the end, debugger and profiler just
provide a more convenient, more efficient but also more indirect
way of instrumenting source code or byte code, respectively.
Considering real-time systems, if too much information
is queried this could result in unusable traces as
well. Fortunately, we can use an emulator to execute the
AXE10 source code as is – no instrumentation is necessary.
The output of tracing information is a configurable built in
functionality of this emulator. Additionally, the virtual time
mode of the emulator guarantees that complex test cases are
possible without running into timing problems.
There are different proposals for the representation of
dynamic information to a reengineer. In most cases, either
collaboration diagrams or different variations of sequence
diagrams are used [21]. Others [9, 18] use different kinds
of non-standard graph representations. In rare cases, there
are even more elaborate representations like the piano-roll
representation in [12]. We have chosen to implement both
a collaboration diagram view and a sequence diagram view
because these kind of representations are very common to
telecommunication engineers. Furthermore, we have implemented
different inspection modes for traces (manual
step-by-step inspection, slow-motion replay with aging, and
batch processing for re-documentation purposes). This provides
a reengineer with maximum flexibility in the processing
and utilization of dynamic information.
When comparing the E-CARES approach of dynamic
information retrieval to other approaches, we found that
the majority of approaches collect this information from
a running system. There are only a few approaches [11]
that derive behavioral information via static analysis. In
E-CARES both static and dynamic analysis are utilized to
retrieve information on a systems’ behavior. Furthermore,
information retrieved from static and dynamic analysis can
be combined to overcome each others’ deficits: E.g., for
state machine extraction, code coverage is guaranteed via
static analysis while the precise dynamic information can
be used to search for potentially invalid transitions. That is,
information can be exchanged between static and dynamic
In the literature, the post-processing of dynamic information
ranges from slicing of program structures, feature
location in code [7], and state machine extraction [22] to
re-documentation of the current implementation. The ECARES
prototype currently comprises state machine extraction
and re-documentation; the implementation of program
slicing (which is related to architecture extraction in
our case) and feature location is still under construction.
8. Conclusion
We have presented tools for understanding the behavior
of telecommunication systems. These tools were developed
in close cooperation with telecommunication experts from
Ericsson. We followed an evolutionary approach to tool development,
i.e., functionality was added incrementally in
response to the requirements stated by the telecommunication
experts. In this way, we took a step towards an environment
which is based on domain-specific concepts.
So far, approximately 500,000 lines of PLEX code plus
several ten thousands of lines of additional documents have
been processed, analyzed, visualized, and inspected on different
levels of abstraction. Understandably, the exact and
detailed results are confidential and cannot be discussed
here. According to the telecommunication experts, the ECARES
prototype allows to visualize the AXE10 software
systems in terms of their daily use, e.g., block dependencies,
state diagrams, link chains, and sequence diagrams.
For that, no tools have been available so far. In particular,
the dynamic analysis tool has proved its value for system
analysis and system understanding. Therefore, we are convinced
that analyzing and visualizing the dynamic behavior
of telecommunication systems is key to system understanding.
Furthermore, we believe that only the combination of
static and dynamic as well as structural and behavioral analysis
– integrated in an interactive reengineering framework
– allows to obtain best possible results.
The current E-CARES prototype is domain dependent to
a certain extent. In particular, the structure graph is tightly
bound to the PLEX programming language, i.e., nodes of
the structure graph correspond to PLEX constructs such as
blocks, signal declarations, signal send statements, etc. At
Ericsson, other programming languages, e.g., C and C++,
are used, as well. To support multi-language systems, we
have started to divide the structure graph into programming
language dependent and language independent aspects. The
final goal is a flexible and extensible reengineering system
that consists of a core system which is extended with specific
functionality in form of plug-in modules. For this purpose,
we are currently defining general interfaces between
the different parts of the system, e.g., between parsers and
static analysis tool, etc. The visualization of extracted information
in form of different views, e.g., structural views,
sequence diagrams, collaboration diagrams, and state machines,
are independent of the current subject of study. Even
the underlying analyses can be readily applied to other realtime
systems, provided that the needed information is available
and storable in terms of our structure graph.
Additionally, we need a neutral representation at the architecture
level. Therefore, we are currently extending the
E-CARES prototype such that it builds a ROOM model
from analyzed programs. Others, like SDL or the component
model of UML 2.0 will be explored in the future.
Finally, we will extend the E-CARES prototype to cover
re-design. That is, we intend to support the restructuring
and extension of existing systems in addition to reverse engineering,
which has been our focus so far.
Acknowledgments The E-CARES project is funded by
Ericsson Eurolab Deutschland GmbH (EED); support is
gratefully acknowledged. We would like to thank the following
members of EED for their constant active support,
critical feedback, and patience: Martin Blumbach, J¨org
Bruss, Axel Jeske, Per Ljungberg, Ari Peltonen, Andreas
Th¨ulig, DietmarWenninger, and Andreas Witzel.
[1] B. B¨ohlen, D. J¨ager, A. Schleicher, and B. Westfechtel. UPGRADE:
Building interactive tools for visual languages.
In Proceedings of the 6th World Multiconference on Systemics,
Cybernetics, and Informatics (SCI 2002), volume
I (Information Systems Development I), pages 17–22, Orlando,
Florida, July 2002.
[2] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling
Language User Guide. Addison Wesley: Reading,
MA, 1999.
[3] G. Canfora, A. Cimitile, A. De Lucia, and G. Di Lucca.
Decomposing legacy systems into objects: An eclectic approach.
Information and Software Technology, 43(6):401–
412, 2001.
[4] E. J. Chikofsky and J. H. Cross II. Reverse engineering and
design recovery: A taxonomy. IEEE Software, 7(1):13–17,
[5] K. Cremer, A. Marburger, and B. Westfechtel. Graph-based
tools for re-engineering. Journal of Software Maintenance
and Evolution: Research and Practice, 14(4):257–292, Aug.
[6] J. Ebert, R. S¨uttenbach, and I. Uhe. Meta-CASE in practice:
A case for KOGGE. In Proceedings 9th International
Conference on Advanced Information Systems Engineering
CAiSE 1997, LNCS 1250, pages 203–216, Barcelona,
Spain, June 1997.
[7] T. Eisenbarth, R. Koschke, and D. Simon. Aiding Program
Comprehension by Static and Dynamic Feature Analysis.
In Proceedings International Conference on Software Maintenance
ICSM 2001, pages 602–611, Florence, Italy, Nov.
[8] J. Ellsberger, D. Hogrefe, and A. Sarma. SDL - Formal
Object-oriented Language for Communicating Systems.
Prentice Hall, 1997.
[9] J. Gargiulo and S. Mancoridis. Gadget: A Tool for Extracting
the Dynamic Structure of Java Programs. In Proceedings
International Conference on Software Engineering
and Knowledge Engineering SEKE 2001, Buenos Aires, Argentina,
June 2001.
[10] R. Kazman, S. G. Woods, and J. Carri`ere. Requirements for
integrating software architecture and reengineering models:
CORUM II. In Working Conference on Reverse Engineering,
pages 154–163, Hawai, USA, Oct 1998.
[11] R. Kollmann and M. Gogolla. Capturing Dynamic Program
Behavior with UML Collaboration Diagrams. In Proceedings
European Conference on Software Maintenance and
Reengineering CSMR 2001, pages 58–67, Lisbon, Portugal,
Mar. 2001.
[12] K. Lukoit, N. Wilde, S. Stowell, and T. Hennessey. Trace-
Graph: Immediate Visual Location of Software Features. In
Proceedings International Conference on Software Maintenance
ICSM 2000, pages 33–39, San Jose, California, USA,
Oct. 2000.
[13] A. Marburger and D. Herzberg. E-CARES research project:
Understanding complex legacy telecommunication systems.
In Proceedings 5th European Conference on Software Maintenance
and Reengineering CSMR 2001, pages 139–147,
Lisbon, Portugal, 2001.
[14] A. Marburger and B. Westfechtel. Graph-based reengineering
of telecommunication systems. In Proceedings of the
International Conference on Graph Transformations ICGT
2002, LNCS 2505, pages 270–285, Barcelona, Spain, Oct.
[15] L. Markosian, P. Newcomb, R. Brand, S. Burson, and
T. Kitzmiller. Using an enabling technology to reengineer
legacy systems. Communications of the ACM, 37(5):58–70,
[16] H. A. M¨uller, K. Wong, and S. R. Tilley. Understanding
software systems using reverse engineering technology. In
The 62nd Congress of L’Association Canadienne Francaise
pour l’Avancement des Sciences ACFAS 1994, pages 41–48,
Montreal, Canada, May 1994.
[17] U. Nickel, J. Niere, and A. Z¨undorf. Tool demonstration:
The Fujaba environment. In Proceedings of the 22nd International
Conference on Software Engineering ICSE 2000,
pages 742–745, Limerick, Ireland, Nov. 2000.
[18] T. Richner and S. Ducasse. Recovering High-Level Views
of Object-Oriented Applications from Static and Dynamic
Information. In Proceedings International Conference on
Software Maintenance ICSM 1999, pages 13–22, Oxford,
England, Sept. 1999.
[19] A. Sch¨urr, A. J. Winter, and A. Z¨undorf. Graph grammar
engineering with PROGRES. In Proceedings 5th European
Software Engineering Conference ESEC 1995, LNCS 989,
pages 219–234, Barcelona, Spain, Sept. 1995.
[20] B. Selic, G. Gullekson, and P. T. Ward. Real-Time Object-
Oriented Modeling. John Wiley & Sons: Reading, MA,
[21] T. Syst¨a. On the Relationships between Static and Dynamic
Models in Reverse Engineering Java Software. In
Proceedings 6th Working Conference on Reverse Engineering
WCRE 1999, pages 304–313, Atlanta, Georgia, USA,
Oct. 1999.
[22] T. Syst¨a and K. Koskimies. Extracting state diagrams from
legacy systems. In Object-Oriented Technology ECOOP’97,
LNCS 1357, Jyv¨askyl¨a, Finland, 1997.
[23] H. J. van Zuylen, editor. The REDO Compendium: Reverse
Engineering for Software Maintenance. JohnWiley & Sons:
Chichester, UK, 1993.
[24] N. Wilde, C. Casey, J. Vandeville, G. Trio, and Hotz Dirk.
Reverse engineering of software threads: A design recovery
technique for large multi-process systems. Journal of Systems
and Software, 43(1):11–17, 1998.
[25] N.Wilde and M. Scully. Software reconnaissance: Mapping
program features to code. Journal of Software Maintenance:
Research and Practice, 7(1):49–62, 1995.

+ نوشته شده در  چهارشنبه یازدهم فروردین 1389ساعت 23:45  توسط سعید  | 


An Expert System For The Development

Of New Telecommunications Services

Armin P.-G. Eberlein Fred Halsall

Department of Electrical & Electronic Engineering, University of Wales

Singleton Park, Swansea SA2 8PP, U.K., Tel: +44 1792 295541, Fax: +44 1792 295686

e-mail: A.Eberlein@swansea.ac.uk


This paper outlines the functionality of an expert system currently under development. It is

called "RATS" (Requirements Assistant for Telecommunications Services) and is designed to

actively assist the development of new telecommunications services. It helps during the early

parts of the development life cycle, during requirements capture and analysis, leading to formal

specifications of the service at different stages of refinement. Facilities for requirements

traceability, rationale and documentation as well as impact analysis of requirements change are

provided. The tool contains comprehensive knowledge bases with the main characteristics of

the telecommunications domain and the development process of telecommunications services,

which enable the tool to actively guide the software developer. These features are

implemented with the help of a formal, object-oriented knowledge representation language

called TELOS. Assistance is provided for three dimensions of the development process of

functional requirements: refinement, formality and completeness. The output of the RATS tool

enables a smooth transition to the ITU recommended Specification and Description Language

(SDL), which allows automated analysis of static and dynamic properties as well as code

generation. The novelties of the RATS tool include active guidance during the development

process of new telecommunications services, a negotiation process between customer

requirements and reuse of existing functionality, a uniform treatment of very different kinds of

requirements at different levels of abstraction, and a smooth transition to ITU recommended

specification methods. Examples from the Universal Personal Telecommunication (UPT)

service illustrate the usage of the tool.

Keywords: expert systems, knowledge based modelling, requirements engineering,

telecommunications, intelligent networks, formal methods

1 Introduction

Studies (e.g. [Boe84]) indicate, that errors associated with requirements are the most

numerous and, even more significantly, they are the most costly and time-consuming to

correct. This has made requirements engineering (RE) a discipline of increasing importance.

Due to the immense amount of information involved in RE for software projects, good tool

support is essential. It has been pointed out [Bub95] that current commercial CASE tools are

not adequate for RE and are therefore not used in RE work. Even commercial RE tools,

which are mostly able to provide basic requirements management functions, cannot provide

domain specific guidance and lack the capability of decision tracking.

These problems have become apparent in the telecommunications domain which, from a

software engineering viewpoint, can be considered as a complex distributed computer system.

It is estimated that at least 70% of the design effort associated with telecommunications is

concerned with the software engineering domain [Ree92]. A lot has already been invested in

order to increase the quality of telecommunications software. One of the major progressions

was the adoption of formal methods. The International Telecommunication Union (ITU)

recommended the use of the Specification and Description Language (SDL) [Z.100] as a

formal, executable language to specify services and protocols. There is now good commercial

tool-support available which allows analysis, verification, execution and validation of SDL

specifications as well as automatic code and test case generation.

The major bottleneck in the cycle is currently found in the process of requirements

elicitation and early analysis in order to get a high quality requirements specification. The

Requirements Assistant for Telecommunications Services (RATS) tool is intended to provide a

front end to currently practised development methods. It actively helps during requirements

elicitation and early analysis while providing a smooth transition to SDL-based formal

methods. Thus it is intended that the RATS tool will overcome the inadequacy of commercial

RE tools. When fully developed, the knowledge based expert system, implemented with the

help of a knowledge representation language (in this case: TELOS [Myl90]), will provide a

feasible solution to today's problems of RE.

2 Overall Methodology For The Design Of New IN Services

The development methodology is shown in

Figure 1. It uses the RATS tool and can be

inserted into already existing life cycles which

use formal methods. It provides a semi-formal

step between the informal service idea and the

formal specification in a specification language

(e.g. LOTOS, SDL). This means that the input

of the RATS tool is the service idea expressed in

customer terms, and the output is in a formal

form easily translatable into SDL.

3 Outline Of The RATS Tool Architecture

The increasing complexity and diversity of the telecommunications domain make it difficult

for a service developer to have detailed expertise of all the factors to be considered during

service design. It, therefore, seams feasible to use a knowledge based approach in order to

alleviate the service designer from knowing all the detailed facts of the telecommunications

domain. In general, the RATS tool comprises of two parts as shown in Figure 2:

the main characteristics of the telecommunications domain

information about the development processes

However, this approach has some disadvantages: changes in the higher layers of the

conceptual model involve considerable effort. Fortunately, the nature of the telecoms domain





in SDL


Requirements Capture Specification

and Analysis

Tool for




vague idea ordered idea semiformal formal





Telecoms Service Provider

Switch Supplier

Service Logic

Call Control Software

Figure 1: The overall methodology for service design

changes relatively slowly due to the

costs involved in major upgrades.

Another problem is the considerable

amount of information necessary to

achieve active assistance during

service development which results

in large knowledge bases. Already

our prototype, which does not yet

contain all the intended information,

has clearly observable response

times which are likely to further increase with the completion of the tool.

3.1 Domain Models

The domain models contain the main characteristics of telecommunication specific issues.

Currently, the RATS prototype contains information from more than 80 recommendations and

standards conceptually expressed in TELOS.

Due to a clear separation of the development and domain models, a great variety of models

can be used within RATS. Very detailed models, which can be seen as electronic versions of

standards and which are suitable for teaching purposes, can be used. Other models might just

contain the absolutely necessary information to support the service design process. This shows

that the RATS tool can accommodate very different kinds of domain models which might have

been created by different people for different purposes. This is possible by introducing a

negotiation layer (see Section 3.3) between the domain models and the development models.

3.2 Development Models

The development models describe a development process suitable for requirements

acquisition and early analysis of telecommunications services. The basic outline of the initial

development process is shown in Figure 3:

The foundation of the model is a sophisticated subclass hierarchy which ensures a

development along three dimensions: completeness, refinement and formality. The process

attempts to leave as much freedom as possible in the beginning in order to make sure that the

end product is really what the customer wants, but then formality is stepwise introduced. This

starts with an initial assignment of requirements to a requirements subclass which then

channels the further development. The further down the subclass hierarchy the designer goes

the less freedom there is. In the case of functional requirements, the subclass hierarchy directs

to an use-case design process [Jac93]. The most formal use-case definition consists of a

semi-formal use-case syntax easily translatable into SDL.

Initial Customer Description


I want to be able

make a phone call

from any phone in

the world to any

phone in the world.

Service Definition Template


. . .

1) Subscriber

2) User

3) User Interface

4) Functional Description

5) Network

6) Billing and Tariff

7) Geographical Coverage

SDL Specification

Service Level

Use-Case Design

overall behaviour

exceptional behaviour

alternative behaviour

normal behaviour

Universal Personal Telecommunication (UPT) Service



Brainstorming List



security important

what networks?

price low!

also for mobiles!

. . .


very important

at least ISDN, PSTN,


price as low as


. . .

security important



business process action



















Domain Knowledge









Development Models

Intelligence Layer

Negotiation Layer

Figure 2: The RATS tool

Figure 3: Requirements acquisition process (example: UPT service)

3.3 The Negotiation Layer

In order to enable the use of different kinds of domain models (cf. Section 3.1) and to offer

active, domain-specific guidance, there needs to be an interface between the development

models and the domain models. Intermodel consistency could be another task of this layer,

however, RATS provides this in the intelligence layer (see Section 3.4).

Despite informal negotiation being very much part of everyday life, negotiation behaviour

during requirements specification has not yet been explored very well [Rob90]. In this case, a

relatively simple approach is taken.

Negotiation objects: These objects form a subclass of the class Requirement. They

therefore inherit all characteristics of this class but fulfil a special function in the chain of

requirements development. From a requirements management viewpoint they are the "end"

of a chain of requirements, i.e. they link to an object in one of the domain models. These

negotiation objects play a special role as they have to perform the connection between the

development process and the different kinds of domain models thus allowing a clear

separation between the models.

Keywords: The negotiation process itself is part of the problem of software reuse [Bel93].

In our case, keyword searches of different categories are employed supported by two kinds

of meta-attributes which can reuse already existing domain objects, or allow new keywords

to be inserted.

As the active support of the negotiation process is done by a string comparison between the

desired keywords provided by the service designer and the keywords assigned to existing

domain features, there is one major impact on the domain models which they have to comply

with. All keywords need to be positive descriptions of the object as negations will lead to

erroneous results. This principle can be termed as "positive modelling".

The combination of the functionality of the negotiation layer and the intelligence layer (cf.

Section 3.4) is a means for active assistance for software reuse. The domain models contain

specification and software modules of generic network functionality available for reuse. This is

one of the main motivations behind the intelligent network concept [Gar93].

3.4 The Intelligence Layer

This section is dedicated to the question of how intelligence can be provided in a system

implemented in TELOS.

3.4.1 Passive Guidance

Passive Guidance can be provided via several means:

a) Conceptual, object-oriented modelling using formal languages provides a certain level of

intelligence. Inheritance, classification, specialisation and instantiation are means for some

basic forms of intelligence. TELOS and its implementation in the ConceptBase tool [Jar93,

Jar96] contains several axioms which are automatically enforced as soon as an object is

inserted into the knowledge base.

b) In addition to these built-in rules and constraints, the created domain models contain a

large number of permanent, user defined constraints and rules which ensure model

consistency. Furthermore, the development models as well as the negotiation layer contain

several constraints and rules which help in the correct development of services.

The two features mentioned in a) and b) prevent the insertion of inconsistent objects into

the knowledge base. However, this is only wanted for serious consistency violations. Some

inconsistencies (especially incompleteness) can be temporarily acceptable [Fin94]. To

accommodate this, two additional solutions have been provided:

c) A set of user defined constraints is available but these are only triggered at certain

milestones of the development life cycle in order to check consistency and completeness.

d) The RATS tool contains, at a high layer of the models, generic meta-rules which assign

an object to certain "state classes" showing the state an object is currently in with respect to

the development process.

All the four rules and constraints are basic but crucial and provide passive guidance ("Don't

do that!"). However, what is expected of an expert system is the additional feature of active

guidance ("Do this!").

3.4.2 Active Guidance

There are again several means how active guidance can be achieved using TELOS. Some of

the possibilities are briefly outlined here:

a) The classes of the development models contain strings which point out the steps which

normally have to be performed. However, this allows only general guidance as it is connected

to a class and not to the current state of a specific instance.

b) Some rough guidance can be derived from the development models. This demands

models which are oriented towards the development process rather than the conceptual

inheritance of characteristics. In many cases these two aspects might be the same, however

this cannot generally be assumed.

c) Special attributes are created which point to the object next to be dealt with. This is

similar to b), except that it leaves more freedom to the conceptual model.

d) The most general approach for active guidance involves the creation of special

intelligence models. Rules ensure the assignment of specific intelligence objects to instances of

any requirements object depending on the actual state of this specific instance. Complex rules

have to be created in order to allow such individual, active guidance.

e) Queries for possible parameters for the intelligence objects can be defined.

3.4.3 Artificial Intelligence In RATS

RATS employs a combination of several of the above mentioned ideas. In order to illustrate

the used approach, a simple example is given:

Let us assume, the UPT service is to be defined. Subsection 3.4.1a) ensures that the

definition is an instance of the class ServiceDefinitionTemplate (which is a subclass of

RequirementsDocument) in order to enable the inheritance of its attributes. Let us say that this

document still contains some requirements which have not yet got the status agreed.

Subsection 3.4.1d) informs the designer that there is still something wrong with this document

and hence the document is assigned to the class InconsistentObject. Subsection 3.4.2d) points

out to the designer that he should try to get the status agreed for all requirements in this

requirements document. Subsection 3.4.2e) points out which particular requirements still need

to get the status agreed. In case the designer ignores these messages and tries to assign the

status agreed to the whole document (even if it still contains requirements without the status

agreed), subsection 3.4.1b) will reject this attempt.

Another task of the intelligence layer is to ensure intermodel consistency. Rules are used to

guarantee meaningful usage of the libraries contained in the independently created domain

models, i.e. that the elements used from different domain libraries fit together. The following

few lines show a rule ensuring that only such a basic network service can be specified in a

service definition which is also offered by one of the chosen networks:

NetworkAndBasicServicesFitTogether_rule : $forall f1/ServiceDefinitionTemplate

(exists e1,e5/NegotiationObject e2/NW e4/Library

(f1 containsNetwork e1) and (f1 containsBasicServices e5) and

(e1 linksToLibrary e2) and (e5 linksToLibrary e4) and

not(exists e3/BasicNWService (e2 offers e3) ==> (e4 in e3)))

==> (f1 IntelligenceObject Int25)$

At the moment, the RATS tool contains altogether some 218 user defined rules and 33 user

defined constraints.

3.5 Requirements Management

Good requirements management is essential in RE. RATS uses a novel, uniform treatment

of very different kinds of requirements which goes beyond the capabilities of currently

available RE tools. It allows a high degree of flexibility and ease of management at all levels of

abstractions. Depending on the kind of requirement and the operation performed on it, default

attributes and links are automatically created. The historical development and the rationale

behind decisions is recorded which is necessary for requirements traceability. In a forward

direction, impact analysis of changing requirements can be assessed by following logical

dependency links between requirements.

4 Conclusions And Future Work

The RATS tool is intended as a step towards a partial solution of the current problems of

tool support for RE. Its strength is that it fits into already existing development life cycles

which employ formal methods. Its main novelties are:

Requirements are captured freely from customers and a best-fit with existing infrastructure

is achieved by negotiation mediated by the RATS tool. The tool uses knowledge about

telecommunication networks and services to actively support this process.

Requirements are managed uniformly and in electronic format, regardless of levels of

abstraction, allowing much improved standards of traceability over current commercial


An intermediate formal description of the service is developed, using the specification

language SDL, in advance to implementation. This encourages complete and unambiguous

specifications and allows early validation activities such as service simulation and feature

interaction analysis.

The prototype of the RATS tool still needs further development and this will influence the

already existing models. Up to now, only small parts of the UPT service have been used to

demonstrate the usefulness of the tool and a more complete case study needs to be developed.

This will also help to make possible performance problems more obvious.

5 References

[Bel93] Bellinzona, R. et al "Reuse of Specifications and Designs in a Development Information

System", IFIP Working Conf. on Inf. Sys. Dev. Process, IFIP WG 8.1, September 1993.

[Boe84] Boehm, B. "Verifying and Validating Software Requirements and Design Specifications",

IEEE Software, 1(1), pp. 94-103, 1984.

[Bub95] Bubenko, J. "Challenges in Requirements Engineering", Second IEEE Int. Symp. on RE,

March 1995.

[Fin94] Finkelstein, A. et al "Inconsistency Handling in Multi-Perspective Specifications", IEEE

TRans. on SW Eng, 20(8), pp. 569-578, August 1994.

[Gar93] Garrahan, J. et al "Intelligent Network Overview", IEEE Com. Magazine, March 1993.

[Jac93] Jacobson, I. "Object-Oriented Software Engineering - A Use-Case driven Approach",

Addison-Wesley, 1993.

[Jar93] Jarke, M. et al "ConceptBase - A deductive Object Base Manager", University of Aachen,

Germany, 1993.

[Jar96] Jarke, M. "ConceptBase V4.0 User Manual", University of Aachen, Germany, 1996.

[Myl90] Mylopoulos, J. et al "TELOS: Representing Knowledge about Information Systems", ACM

Trans. Inf. Systems 8 (4), pp. 325-362, 1990.

[Ree92] Reed, R. et al "Methods for Service Software Design", IEE 1992.

[Rob90] Robinson, W. "Negotiation Behaviour During Requirements Specification", IEEE 1990.

[Z.100] ITU-T Recommendation Z.100 "CCITT Specification and Description Language (SDL)",


+ نوشته شده در  دوشنبه نهم فروردین 1389ساعت 13:35  توسط سعید  | 

آموزش Photoshop


فتوشاپ یکی از نرم افزارهای گیرافیکی است که اساس کار آن بر پایه ی Bitmap می باشد .
نرم افزار فتوشاپ متعلق به شرکت Adobe بوده و برای ویرایش تصاویر ، طراحی موارد گرافیکی چاپی یا غیر چاپی و ... مورد استفاده ی کاربران قرار می گیرد .
ضمن اینکه این نرم افزار با چاپگرها و دستگاههای خروجی فیلم و زینک بصورت استاندارد هماهنگی دارد .
برای مطالعه ی این دوره ی آموزشی نیاز است کاربران محترم آشنایی با سیستم عامل ویندوز داشته باشند .

ضمنا سیستم شما باید دارای مشخصات سخت افزاری ذیل باشد :

- حداقل سیستم مورد نیاز پنتیوم 233
- 16 مگابایت Ram
- حدود 600 مگا بایت فضای آزاد
- کارت گرافیکی 64 گیگا بایت

ادامه مطلب
+ نوشته شده در  جمعه نوزدهم تیر 1388ساعت 12:41  توسط سعید  | 

معرفي رشته مهندسي فناوري اطلاعات

رشته مهندسي فناوري اطلاعات يكي از جديدترين رشته هاي دانشگاهي در ايران است. اين رشته در سال 81 مورد پذيرش وزارت علوم قرار گرفت و تا به حال در سال هاي تحصيلي 81-82 و 82-83 اين رشته ارائه شده است . برخي از مهمترين دانشگاه هايي كه اين رشته در آنها ارائه مي شود عبارتند از : صنعتي شريف, علم و صنعت, تربيت مدرس و پلي تكنيك.

كارشناسي ارشد اين رشته نيز از همان سال شروع به پذيرش دانشجو كرده است. در ادامه با توجه به آغاز ثبت نام آزمون كارشناسي ارشد به معرفي دروس اين رشته مي پردازيم و ضرايب و گرايش هاي كارشناسي ارشد اين رشته را بررسي مي كنيم.


دروس اين مقطع بسيار شبيه به دروس رشته كامپيوتر است و تقريبا دروس اصلي آن با دروس گرايش نرم افزار مهندسي كامپيوتر يكسان است ولي دروس تخصصي و اختياري آن تقريبا به طور كامل با آن متفاوت است. مجموع واحد هايي كه دانشجو براي اخذ مدرك ليسانس بايد بگذراند 149 واحد است.

_ دروس پايه و عمومي :

مجموعا شامل 41 واحد است. 20 واحد عمومي و 21 واحد پايه. دروسي مانند رياضي ۱ , فيزيك۱ و ... جزو دروس پايه اين رشته است و دروس عمومي آن شبيه ساير رشته هاي دانشگاهي شامل دروسي مانند معارف, انقلاب, فارسي عمومي و... است.

_ دروس اصلي :

مجموعا شامل 62 واحد است و در كل تنها در چهار درس (شبكه هاي كامپيوتري 2 , اقتصاد مهندسي , آز شبكه و مباني الكترونيك ديجيتال ) يعني 10 واحد با دروس اصلي رشته مهندسي كامپيوتر فرق دارد. اسامي اين دروس و ضرايب آنها به قرار زير است:
ساختمان هاي گسسته 3
مباني كامپيوتر و برنامه سازي 4
زبان ماشين و برنامه نويسي سيستم 3
ساختمان داده 3
مدار منطقي 3
معماري 3
برنامه سازي پيشرفته 3
سيستم عامل 3
نظريه زبان و ماشين 3
پايگاه داده 3
طراحي الگوريتم 3
مهندسي نرم افزار 1 3
مهندسي نرم افزار 2 3
شبكه هاي كامپيوتري 1 3
شبكه هاي كامپيوتري 2 3
مباني الكترونيك ديجيتال 3
هوش مصنوعي 3
اقتصاد مهندسي 3
آزمايشگاه شبكه 1
آزمايشگاه پايگاه داده 1
ارايه مطالب 2
زبان تخصصي 2
آز سيستم عامل 1

_ دروس تخصصي : مجموعا شامل 31 واحد است كه بطور كامل با دروس تخصي رشته مهندسي كامپيوتر متفاوت است. اسامي اين دروس و ضرايب آنها به قرار زير است:
مباني فناوري اطلاعات
مهندسي فناوري اطلاعات
تجارت الكترونيك
مديريت و كنترل پروژه فناوري اطلاعات
مهندسي فناوري اطلاعات 2
گرافيك كامپيوتري
اصول و مباني مديريت
مولتي مديا
پروژه فناوري اطلاعات

_دروس اختياري :

دروس اختياري دروسي است كه دانشجو بايد از ميان آنها به دلخواه 5 درس يعني 15 واحد را انتخاب كند. از ميان اين دروس درس هايي ما نند" گرافيك و خبره "به دانشجويان رشته نرم افزار نيز ارائه مي شود. اسامي اين دروس و ضرايب آنها به قرار زير است.

مديريت نگهداري فناوري اطلاعات
تحقيق در عمليات
سيستم هاي خبره
مديريت رفتار سازماني
تعامل انسان و كامپيوتر
مباحث نو در فناوري اطلاعات
سيستم اطلاعات جغرافياييGIS
شبيه سازي كامپيوتري
طراحي و پياده سازي كتابخانه الكترونيك
بهينه سازي كاربردي
نرم افزارهاي توزيع شده
آموزش مجازي

كارشناسي ارشد :
اين مقطع شامل نيمسال تحصيلي است و در 32 واحد به دانجويان ارائه مي شود. پذيرش از رشته هاي مهندسي كامپيوتر, مهندسي الكترونيك و مهندسي صنايع نيز صورت مي گيرد.

_گرايش ها

1- تجارت الكترونيكي
2-سيستمهاي چند رسانه اي
3-مديريت سيستمهاي اطلاعاتي
4-امنيت اطلاعات
5- شبكه هاي كامپيوتري
6- مهندسي فناوري اطلاعات (IT)

_ضرايب دروس و مواد امتحاني :

1- زبان تخصصي، 2-دروس مشترك (شامل ساختمانهاي گسسته، ساختمانهاي داده ها، طراحي الگوريتم، مهندسي نرم افزار ، شبكه هاي كامپيوتري) 3- اصول و مباني مديريت، 4- اصول طراحي پايگاه داده ها، 5- هوش مصنوعي، 6- سيستمهاي عامل، 7- معماري كامپيوتر. ضرايب به ترتيب دروس عبارتند از:
1- تجارت الكترونيكي (1، 2، 1، 1، 1، 1و0) 2-سيستمهاي چند رسانه اي (1، 2، 1، 1، 1، 1 و0 )
3- مديريت سيستمهاي اطلاعاتي (1، 2، 2، 1، 1، 1 و0) 4 - امنيت اطلاعات (1، 2، 0، 1، 1، 1و 1)
5- شبكه هاي كامپيوتري (1، 2، 0، 1، 1، 1 و 1)6- ضرايب همانند گرايش تجارت الكترونيكي

_ دروس دوره ارشد :
الف- دانش زير بنائي (دروس اصلي پايه) 6 واحد
ب- دانش عمليات تخصصي (دروس اصلي تخصصي) 9 واحد
پ- دانش يك حوزه تخصصي (دروس اختياري) 9 واحد
ج- سمينار و روش تحقيق در فناوري اطلاعات 2 واحد
د- پروژه كارشناسي ارشد 6 واحد

_چند نكته:
با توجه به گرايشات مختلف دروس اصلي تخصصي در دو گرايش ( سيستمهاي تكنولوژي اطلاعات ITS و تكنولوژي اطلاعات و ارتباطات ITC ) ارائه مي شود.

براي پذيرفته شدگاني كه رشته كارشناسي آنها IT نبوده است حداكثر شش واحد جبراني بصورت پيش نياز ارائه مي شود.

_ دروس اصلي ( مشترك )
مديريت و برنامه ريزي منابع اطلاعاتي ۳
مهندسي مجدد الكترونيكي فرايندهاي كسب و كار ۳

_ دروس تخصصي ( ITC )
شبكه هاي كامييوتري و انتقال داده ها ۳
ارزيابي عملكرد سيستم هاي كامپيوتري ۳
سيستم هاي خبره و مهندسي دانش ۳

_ دروس تخصصي ( ITS)
واسط هاي تجارت الكترونيك ۳
بازاريابي استراتژيك بر روي اينترنت ۳
استراتژي تكنولوژي اطلاعات ۳

منبع www.farstec.com
+ نوشته شده در  شنبه سیزدهم تیر 1388ساعت 21:1  توسط سعید  | 

زیرساختار فناوری اطلاعات برای تعطیلات تابستان

توجه به نیازهای اطلاعاتی و آموزش صحیح آن برای کودکان و نوجوانان در حوزه فناوری اطلاعات و ارتباطات یک نگاه راهبردی به شمار میرود.اگر کودکان و نوجوانا در دهه های پیش با گچو قلم آموزش داده می شدند، امروزه حق آنهاست که با سیتم های آموزشی پیشرفته و با بهترین کیفیتدر دسترس آموزش ببینند.دولت های پیشرفته دنیا نتیجه آموزش با کیفیت کودکان و نوجوانان بوسیله استانداردهای فناوری  آموزشی جهانی را دیده اند.

اینکه فکر کنیم محروم کردن یا بی توجهی به قشر کودک و نوجوان در حوزه فناوری را میتوان با ارجاع این نسل به دورا رشد و بلوغ و رشد و جبران ان تقویت کرد،در حقیقت یک اشتباه بزرگ را مرتکب شده ایم.کودکی که امروز با فناوری مانوس نشود و حقوق او در این دنیای دیجیتال رعایت نشود،در آینده پشتوانه قوی و موثری برای بهره برداری بهتر از این دنیای دیجیتال مدرن در اختیار نخواهد داشتو این بالاترین میزان آسیب پذیری دیجیتالی است که دولت ها در حوزه ی بی توجه به حقوق کودکان و نوجوانان در دنیای فناوری با آن مواجه می شوند.از انجا که اوقات فراغت نقش مهمی در پرورش استعدادهای فرد دارد و میتواند توانایی بالقوه فرد را شکوفا سازد و زمینه علاقه مندی افراد به جنبه های مختلف زندگی را فراهم آورد،با شروع تعطیلات سه ماهه تابستان یکی از مسائلی که در جامعه مطرح میشود و نقش پررنگی به خود میگیرد،مساله اوقات و فراغت کودکان و نوجوانان است.امروزه در فصل تابستان و تعطیلی مدارس، اغلب دانش آموزان برای پر کردن اوقات فراغت خود از کامپیوتر استفاده می کنند.کامپیوتر یکی از ابزارهایی هست که امروزه در اغلب منازل جایی برای خود باز کرده و کاربران آن اغلب کودکان،نوجوانان و جوانان هستندو چه بسا برخی از والدین نحوه کار کردن با آن را نمی دانندو حتی تمایلی جهت آموزش آن ندارند.نظر به افزایش بازیهای کامپیوتری و سرگرمی های اینترنتی در چند سال اخیر،بسیاری از نوجوانان و کودکان برخلاف گذشته ترجیح می دهند پای کامپیوتر نشسته و به بازی یا فعالیتهای اینترنتی مشغول شوندکه بنا بر تحقیقات انجام شده ،بازی های کامپیوتری که این روزها اغلب محتوای خشن دارند،کودک را در معرض افزایش رفتارهای پرخاشگرانه قرار می دهند،به خصوص اگر به صورت مداوم استفاده شوند و کودک زمان زیادی را به این بازیها اختصاص دهد.در مورد نوجوانانی که از اینترنت استفاده می کنند نیز این خطر وجود دارد که با در نظر گرفتن سن انها و نزدیک شدن به شرایط بلوغ،آنها بخواهند همه اوقات فراغت شان را به کنکاش در فعالیت های هیجان انگیز اینترنتی مثل چت کردن یا گشت و گذاردر شبکه های اجتماعی اختصاص دهند.در این صورت علاوه بر اینکه مزایای فعالیت های اجتماع را از دست داده اند،به اینترنت وابستگی پیدا کرده و در معرض ابتلا به افسردگی و اختلالات خلق و خوی قرار می گیرند و علاوه بر آن افزایش میل به تنهایی و دور گزیدن از اجتماع که از تبعات اعتیاد به اینترنت به شمار می رود؛ گریبانگیر می شود.

بدیهی است که برنامه ریزی برای فرهنگ ملی از طریق استفده بهینه از اوقات فراغت فرزندانمان بوسیله فناوری اطلاعات،بدون توجه به تحولات جهانی،نمیتواندذ تاثیر گذار باشد.مکانیزه کردن آموزشگاهها، فرهنگ سراها ،مراکز فرهنگی و هنری و حتی مجتمع های تفریحی به سیستم های شبکه ای دیجیتالی و اینترنتی مناسب ،نیاز روز جامعه کودک و نوجوان برای آموزش و تجربه استفاده صحیح و درست از کامپیوتر،اینترنت و تکنولوژی های جدی د فناوری اطلاعات است.دولت باید در برنامه دراز مدت توسعه کشور با سرمایه گذاری و حمایت ازب بخش خصوصی برای رشد آموزشی مستقیم و غیر مستقیم کودکان و نوجوانان در زمینه فناوری اطلاعات و ارتباطات، به این امر بعنوان یک نیاز توسعه کشور بنگرد.همچنین حمایت ویژه دولت از طراحان نرم افزارهای آموزشی و تفریحی کودکان و نوجوانان که با تعامل و همکاری وزارت آموزش و پرورشو با همیاری شوراهای غالی فناوری اطلاعات در کشور تهیه میشوند و توزیع آن از طریق یک کانال صحیح توزیعی که به سهولت و با هزینه مناسب در اختیار خانواده ها قرار گیرد،میتواند نقش به سزایی در پیشرفت آموزشی،رشد خلاقیت،نحوه استفاده صحیح از کامپیوتر و تکنولوژی ها و فناوری های روز و از همه مهمتر پر کردن اوقات فراغت کودکان و نوجوانان در تعطیلات تابستانی با بهره وری بالا را به همراه داشته باشد.

+ نوشته شده در  چهارشنبه سوم تیر 1388ساعت 15:41  توسط سعید  | 

آشنایی با نرم افزار Windows Movie Maker

بي‌ترديد جلوه‌هاي ويژه بسيار قدرتمند فيلم‌هاي امروزي براي همه ما جذاب و مسحور كننده است. توليدكنندگان ميليون‌ها دلار سرمايه‌گذاري مي‌كنند تا در پوشش جلوه‌ها و انيميشن‌هاي كامپيوتري، فيلم‌ها را به خاطراتي فراموش نشدني و ماندگار در ذهن بينندگان تبديل كنند. بسياري از ما كه به صورت تفريحي و آماتور فيلم مي‌سازيم، قادر به صرف هزينه‌هاي ميليوني نيستيم. با اين حال دوست داريم توانايي خود را در توليد و ارائه محصولي مناسب و با كيفيت نشان دهيم. ويندوز XP اين نياز ما را با ابزار Windows Movie Maker برطرف كرده است. اين نرم‌افزار همراه ويندوز، يك ابزار توانمند و مناسب براي ايجاد، وارد كردن فيلم‌ها و عكس‌ها از دوربين، ويرايش و ذخيره‌ فيلم‌ها و عكس‌هاي خانگي به شمار مي‌رود. در این ترفند قصد داریم تا به بررسی کامل از نرم افزار بپردازیم.

انتقال فايل‌هاي ويديويي و عكس‌
اولين چيزي كه قبل از آغاز عمليات ويرايش فيلم‌ها نياز داريد، انتفال فيلم‌ها به كامپيوترتان است.
مي‌خواهيم فيلم‌هايمان را با استفاده از عكس‌ها و ويديوهاي كوتاهي كه قبلاً تهيه كرده ايم، ايجاد كنيم.
به اين منظور از دوربين ديجيتالي 2/‌7 مگاپيكسلي  Casio Exilim EX Z750 استفاده كرديم كه مي‌تواند ويديو و صدا را نيز ضبط كند. عكس هايمان را نيز با فرمت تصويري Joint Photographic Experts Group)‌ JPEG) به كامپيوتر انتقال داديم و صدا را نيز با فرمت Audio - Video Interleaved) AVI ) كه براي استفاده و كار در نرم‌افزار MovieMaker  بسيار آسان و بي دردسر است، در كامپيوتر ذخيره نموديم.

قدم بعدي، وارد كردن فايل‌ها به MovieMaker است. در MovieMaker يك سند جديد باز كنيد و روي پيوند Import Video كه در قسمت Capture Video واقع در سمت چپ صفحه مانيتور شما قرار گرفته است، كليك كنيد. پس از كليك Import Video با استفاده از منوي پايين افتادني Look In واقع در بالاي كادر محاوره‌اي Import File به محل ذخيره فايل مورد نظر برويد. هنگامي كه فايل را يافتيد، با كليك آن را انتخاب كنيد. در پايين و سمت چپ كادر محاوره‌اي، بخش ‌Import Options حاوي گزينه Create Clips For Video Files همراه با يك مربع تيك خورده، وجود دارد.

با انتخاب اين گزينه هنگام وارد كردن فايل ويديو، MovieMaker آن را براي اضافه كردن افكت‌ها و جلوه‌هاي تصويري به چند بخش كوچك‌تر تكه تكه خواهد كرد. اگر مي‌خواهيد خودتان ويديو را برش دهيد، هنگام وارد كردن آن، گزينهCreate Clips For Video Files را از حالت انتخاب خارج كنيد.

ويرايش فيلم
ممكن است به توانايي‌ها و امكانات يك برنامه ويرايشگر رايگان كه همراه با سيستم‌عاملي همچون ويندوز ارائه شده باشد، خوش بين و مطمئن نباشيد، ولي MovieMaker يك ابزار ويرايشگر قوي، قابل اطمينان و با قابليت استفاده و كاربرد بسيار آسان است.

پس از اين‌كه فيلمتان را به MovieMaker وارد كرديد، آن را در مدياپلير موجود در سمت راستِ صفحه‌‌نمايش تماشا كنيد. هنگام نمايش فيلم در مدياپلير، نقاطي را كه مي‌خواهيد فيلم از آن جا برش بخورد و دو تكه شود، انتخاب كنيد. با كليك دكمه Split Clip فيلم از آن نقطه برش مي‌خورد و تكه بريده شده در قالب يك كليپ جديد ايجاد مي‌شود. اين كليد در قسمت پايين و سمت راست مدياپلير قرار دارد.

وقتي فيلم را در قالب كليپ‌هاي جداگانه تفكيك كرديد، گام بعدي، اضافه كردن افكت و جلوه‌هاي تصويري است. توجه كنيد كه در پايين صفحه، رديفي از جعبه‌هاي خالي تعبيه شده است.‌اين قسمت Storyboard نام دارد.
با كليك كليپ‌هاي مجتمع در قسمت مياني بالاي صفحه و كشيدن آن‌ها به سمت جعبه‌هاي موجود در Storyboard ، تكه فيلم ها را به داخل جعبه‌هاي مورد نظر هدايت كنيد. وقتي كليپ‌ها را در جاهاي صحيح منظم كرديد، مي‌توانيد افزودن افكت‌هاي تصويري را آغاز كنيد.

دو الگوي اصلي براي ويرايش وجود دارد كه مي‌توانيد از آن‌ها استفاده كنيد: Video Effects و Video Transitions.
Video Effects اصلاحاتي مانند افزايش يا كاهش روشنايي و نور، تغيير رنگ يك كليپ يا افزايش و كاهش سرعت نمايش فيلم را شامل مي‌شود. روي پيوند View Video Effects كليك كنيد تا ببينيد MovieMaker در اين بخش چه نمونه‌ها و امكاناتي را ارائه داده است.

اگر خواستيد يك تكه كليپ ديگر را به قسمتي از فيلمتان بچسبانيد، كافي است با كليك و كشيدن كليپ جديد به محل مناسب، آن را در جاي مورد نظر قرار دهيد.

به طور مشابه، مي‌توانيد جلوه‌هاي بصري Video Transitions را در ميان دو كليپ از فيلم قرار دهيد. اين‌ها تكنيك‌ها و جلوه‌هاي بصري جالبي براي پايان يك صحنه و آغاز صحنه بعدي هستند كه توجه بينندگان را به خوبي جلب مي‌كنند.

كار‌ ‌با Video Transitions شبيه Video Effects است. تنها به جاي كشيدن يك Video Transition روي يك كليپ، بايد آن را روي مربع‌هاي كوچك ميان دو كليپ در Storyboard بكشيد و قرار دهيد. با كليك روي Effectها و Transitionها تمام آن ها را دوباره اجرا و بازبيني كنيد و سپس روي دكمه Play در مدياپلير كليك كنيد.

افزودن موسيقي متن به فيلم
يك موسيقي متن مناسب مي‌تواند به جذابيت هر فيلم بزرگ يا حتي فيلم‌هاي بسيار كوچكي كه از چينش تعدادي تصوير در كنار هم  درست شده‌اند (Slideshow) كمك كند. MovieMaker به آساني امكان وارد كردن يك فايل صوتي كامل و مناسب براي فيلمتان را مهيا كرده است.

وارد كردن فايل صوتي (Import) به طور كلي شبيه وارد كردن فايل‌هاي ويديويي است. كار را با كليك روي پيوندImport Audio or Music در قسمت Capture Video از ستون Movie Tasks آغاز كنيد. سپس از منوي پايين افتادنيِ Look In  براي انتخاب  موسيقي مورد نظر استفاده كنيد.

پس از يافتن موسيقي آن را انتخاب نماييد و به MovieMaker وارد كنيد. اين فايل موسيقي به انتهاي فهرست مجموعه فايل هاي پروژه اضافه خواهد شد.

روي دكمه Show Timeline كليك كنيد. مي‌توانيد از اين نما براي ديدن زمان كلي اجراي پروژه و كنترل هماهنگي صدا و تصوير استفاده كنيد.

اگر مي‌خواهيد فايل موسيقي‌اي كه به MovieMaker وارد كرده‌ايد را به فيلم اضافه كنيد، كافي است روي فايل موسيقي از ميان فايل‌هاي پروژه كليك كنيد و آن را به قسمت مربوط به صدا در نوار Timeline بكشيد. مي‌توانيد اندازه زماني فايل صوتي را نيز  با كليك در قسمت Timeline و كشيدن يك لبه موسيقي براي تناسب و هماهنگي با فيلم تنظيم كنيد.

ذخيره فيلم
مي‌خواهيد مانند هر فايل ديگري فيلمتان را ذخيره كنيد. براي انجام دادن اين كار، در ستون Movie Tasks واقع در سمت چپ صفحه بخش Finish Movie را بيابيد.

MovieMaker چند گزينه مختلف براي ذخيره در اختيار شما قرار مي‌دهد، مانند ذخيره فيلم در كامپيوتر يا روي CD، امكان فرستادن فيلم به يك دوربين ويديويي ديجيتال، انتشار در وب يا ارسال به ايميل در قالب يك فايل ضميمه.
با كليك روي پيوند Save to My Computer، گزينه ذخيره روي كامپيوتر را انتخاب كنيد.

ويزارد Save Movie باز خواهد شد. در اولين جعبه متني،  نامي را براي فيلم وارد كنيد. در قسمت دوم محل ذخيره فيلم را انتخاب كنيد. پس از انتخاب نام و محل ذخيره‌سازي با كليك روي Next به قسمت انتخاب كيفيت مورد نياز براي ذخيره فيلم مي‌رويد. با انتخاب مقدار پيش‌فرض Windows MovieMake فيلم را با بهترين كيفيت ممكن ذخيره مي‌كند.

اگر نگران كمبود فضاي روي ديسك سخت براي ذخيره با بهترين كيفيت هستيد، مي‌توانيد از گزينه‌هاي ذخيره‌سازي ديگر استفاده كنيد. همچنين مي‌توانيد فيلم را براي پخش روي موبايل ذخيره كنيد.

بعد از انتخاب متد ذخيره‌سازي، روي Next كليك كنيد. MovieMaker فيلم را به فرمت WMV تبديل و در مكان مشخص شده ذخيره مي‌كند.

حتي پس از پايان كامل كار و ذخيره فيلم، اين احتمال وجود دارد كه فكر و ايده خوبي براي افزودن به فيلم به ذهنتان خطور كند. بنابراين حتماً قبل از بستن پروژه، حتماً يك نسخه از آن را با پسوند MSWMM در مكاني از كامپيوترتان ذخيره كنيد. اين كار كاملاً شبيه ذخيره پروژه‌هاي Word يا Excel است. با انتخاب گزينه Save Project از منوي File، مي‌توانيد نسخه MSWMM پروژه را ذخيره كنيد.

سپس نام و محلي براي ذخيره انتخاب كنيد و روي Save كليك نماييد. هر گاه خواستيد ويديو يا موسيقي جديدي به اين فيلم اضافه كنيد، كافي است فايل MSWMM را باز كنيد و ويديوها، موسيقي‌ها يا جلوه‌هاي تصويري جديد را اضافه كنيد.

Windows MovieMaker يك راه مناسب براي انتقال فيلم‌هاي خانگي به كامپيوتر و افزودن جلوه‌هاي تصويري و ويرايش فيلم‌ها است. در اين نرم‌افزار فايل‌هاي صوتي و تصويري به آساني به محيط كاري نرم‌افزار وارد مي‌شوند و نرم‌افزار جلوه‌هاي بصري فراوان و متنوعي را براي افزودن به فيلم و جلب توجه بيشتر مخاطبان در اختيار كاربر قرار مي‌دهد.

اگر در جست‌وجوي يك برنامه ويرايشگر با كاربرد آسان براي زيباتر‌‌كردن ويديوهاي خانگي خود هستيد، رويWindows MovieMaker به عنوان يك گزينه خوب حساب كنيد.

+ نوشته شده در  شنبه نوزدهم اردیبهشت 1388ساعت 11:21  توسط سعید  | 

آشنایی مختصری با نرم افزار Camtasia Studio


Camtasia Studio يک راه حل کامل جهت : ضبط ، ويرايش و نمايش صفحه نمايش هاي Video يي و انتشاراتي مي باشد .با پشتيباني از انواع Video هاي Standard شما مي توانيد از تحويل محتوياتتان در حال و آينده مطمئن باشيد.Camtasia Studio راه حلي است کاملا حرفه اي براي ضبط ، ويرايش و به اشتراک گذاشتن File هايتان با بهترين کيفيت بر روي : Web ، CD-ROM ، رسانه هاي قابل حمل همچون iPod . ضبط آسان صفحه ي نمايش شما ، PowerPoint ، Multiple audio tracks و Webcam Video براي توليد Video هاي آموزشي ، Screencasts ( آن هم بدون اختلال و ترک ) از ديگر قابليت هاي اين نرم افزار مي باشد. Camtasia Studio  شما را در اين دنياي متحرک کمک خواهد کرد ، آن هم با ساخت آسان Video ها ، Mp3 ها براي iPod يا ساير وسايل قابل حمل . اکنون شما مي توانيد پيام هاي تبليغاتي ، Screencast ، سخنراني ها و يا Video هاي آموزشي را براي شنوندگان خود در هر جايي از اتوبوس گرفته تا Coffee Shop و يا ... عرضه کنيد .
TechSmith Camtasia Studio 6.0.02 از نظر ديگر نمونه اي از يک طرح به اشتراک گذاري نيز می باشد.

قابليتهاي عمومي نرم افزار TechSmith Camtasia Studio 6.0.0:
- Record Anything : قابليت توليد آسان فيلم هاي آموزشي ، نمايشي و سخنراني ها و ساير جريان هاي Online و امکاناتي بي پايان. شما مي توانيد هميشه به طرق مختلف از قبيل:
Screen recordings ، audio ، voice ، Narration ، PowerPoint ، Picture-in-Picture و Webcam Video با شنوندگان خود در ارتباط باشيد.
- Edit and Enhance : قابليت ويرايش و افزايش Video هايتان از طريق : نوشته ها ، عنوان ها ، نسبت ها ، بزرگ و کوچک کردن تصاوير ، حرکت هاي Graphic ي و صداي افزوده شده .پهناوري و بزرگ بودن Option هاي بخش ويرايش Camtasia Studio آنقدر بالاست که تمامي نيازهاي شما را بر طرف خواهد کرد.
- Share : قابليت خروجي هاي متنوع از قبيل : Flash ، QuickTime و ساير Format هاي رايج.
شما پس از خروجي قادر به اشتراک گذاشتن File هايتان بر روي Web ، CD و يا DVD هستيد. حتي شما مي توانيد از هدايت کننده هاي ارائه شده ، در انتخاب بهترين Format و تنظيمات براي قسمت اشتراک گذاري براي شنوندگانتان ياري گيريد. يا حتي شما قادر به Control کامل بر روي صدا ، video Codecs ، کيفيت تصاوير ، سرعت انتقال تصاوير ، عمق رنگ ها و شمول و ممانعت در جلوه هاي ويژه هستيد.

قابليتهاي كليدي نرم افزار TechSmith Camtasia Studio 6.0.0:
Record : ضبط تمام یا قسمتی از صفحه
- ضبط تصاوير WebCam
- ضبط صداهاي ورودي و يا صداهاي داخل System
- ضبط تمام عناصر و داده هاي ارائه شده توسط PowerPoint
شامل : slide timing ، animations و voice Narration
- ضبط Click هاي Mouse و همچنين ضربه هاي صفحه کليد
- ضبط لايه هاي Windows و فعل و انفعالات نرم افزارها
- Capture کردن تنها يک Frame براي تصاوير ساکن در AVI Slideshow
- مرحله بندي کردن ميان Recording با تعيين کمک کننده ها براي کاربران
- ارائه ي Codec هاي جديد توسط TechSmithجهت ارائه دادن Video هايي با کارايي بالا براي سريه و ساده بودن recording
- Preview ي مراحل قبلي يک audio براي recording
- ضبط صداهاي ورودي از Microphone
- اضافه کردن زمان هک شده و نوشته ها بر روي تصاوير
- اضافه کردن نوشته حتي هنگام ضبط
- افزودن و تغيير نوشته ها در ScreenPad Shapes
- اضافه کردن سايه
- Use time-lapse recording
- Record annotation Drawings with ScreenDraw
Edit and Enhance :
- افزودن تصاوير از digital video file ها براي توليدات شخصي با خروجي هاي : WMV, MPEG و AVI
- اضافه کردن تکه هاي Audio شامل : WAV و MP3
- افزودن تصاوير ساکن شامل : BMP ، JPG و GIF
- انتخاب يا Cut کردن بخشي از Video
- انتخاب يک frame از تصوير براي تفيک يک Video در 2 تا
- Zoom کردن در timeline براي دقت در تک تک frame ها
- انتخاب بخشي از يک Frame با خروجي BMP
- ويرايش ، باز بيني ، بريدن و اضافه کردن AVI clips
- باز بيني و تغييرات شما در ويرايش براي real-time
- تغيير اندازه و تفکيک کردن پنجره هاي Preview
- استفاده از 18 تصوير جديد ميان تصاوير
- و...

Publish : خروجي هايي با format هاي Standard و رايج دنيا همچون :
Macromedia Flash ، AVI ، Microsoft Windows Media ، RealNetworks RealMedia و QuickTime
- ايجاد Production Wizard و کمک کننده ها با قابليت انتخا ب ويژگي ها
- خروجي animated GIF
- خروجي EXE file با Pack و Show
- خروجي Video هاي متعدد در يک زمان با توليد دسته اي
- انتخاب List ي از codec ها براي مطابقت دادن با مطالب
- انتخاب عمق رنگ و سرعت انتقال
- انتخاب کيفيت صدا
- و...


+ نوشته شده در  شنبه نوزدهم اردیبهشت 1388ساعت 11:8  توسط سعید  |