MC 0069 01

SYSTEMS ANALYSIS AND DESIGN

9) Explain the 3 steps to be considered to model an API
If a developer whos assembling a system from component parts, hell want to see the
application programming interfaces (APIs) that he can use to glue these parts together.
APIs represent the programmatic seams in his system, which he can model using
interfaces and components.
An API is essentially an interface that is realized by one or more components. As a
developer, well really care only about the interface itself; which component realizes an
interfaces operations is not relevant as long as some component realizes it. From a
system configuration management perspective, though these, realizations are important
because we need to ensure that, when we publish an API, theres some realization
available that carries out the APIs obligations. Fortunately, with the UML, we can
model both perspectives.
The operations associated with any semantically rich API will be fairly extensive, so
most of the time we wont need to visualize all these operations at once. Instead, well
tend to keep the operations in the backplane of our models and use interfaces as handles
with which we can find these sets of operations. If we want to construct executable
systems against these APIs, we will need to add enough detail so that our development
tools can compile against the properties of our interfaces. Along with the signatures of
each operations, well probably also want to include uses cases that explain how to use
each interface.

To model an API,
-

Identify the programmatic seams in our system and model each seam as an
interface, collecting the attributes and operations that form this edge.

Expose only those properties of the interface that are important to visualize in the
given context; otherwise, hide these properties, keeping them in the interfaces
specification for reference, as necessary.

Model the realization of each API only insofar as it is important to show the
configuration of a specific implementation.

The following diagram exposes the APIs of the executable . We can see four interfaces
that form the API of the executable: IApplication, IModels, IRenderering and IScripts.

8) Explain the five parts of a transition.

A transition is a relationship between two states indicting that an object in the first state
will perform certain actions and enter the second state when a specified event occurs and
specified conditions are satisfied. On such a change of state, the transition is said to fire.
Until the transition fires, the object is said to be in the source state; after it fires, it is said
to be in the target state. For ex, a Heater might transition from the Idle to the Activating
state when an event such as Too Cold ( with the parameter desired Temp) occurs.

A transition has five parts.

a) Source State
The state affected by the transition; if an object is in the source state, an outgoing
transition may fire when the object receives the trigger event of the transition and if the
guard condition, if any, is satisfied.
b) Event trigger
The event whose reception by the object in the source state makes the transition
eligible to fire, providing its guard condition is satisfied.
c) Guard condition
A Boolean expression that is evaluated when the transitions triggered by the
reception of the event trigger; if the expression evaluates True, the transition is eligible
to fire; if the expression evaluates False, the transition does not fire and if there is no
other transition that could be triggered by that same event, the event is lost.
d) Action
An executable atomic computation that may directly act on the object that owns
the state machine, and indirectly on other objects that is visible to the object.
e) Target state
The state that is active after the completion of the transition

A transition is rendered as a solid directed line from the source to the target state. A self
transition is a transition whose source and target states are the same.

A transition may have multiple sources (in which case, if represents a join from multiple
concurrent states) as well as multiple targets (in which case, it represents a fork to
multiple concurrent states).
Event Trigger:An event is the specification of a significant occurrence that has a location in
time and space. In the context of state machines, an event is an occurrence of a stimulus
that can trigger a state transition. Events may include signals, calls, the passing of time,
or a change in state. A signal or a call may have parameters whose values are available
to the transition, including expressions for the guard condition and action. it is also
possible to have a triggerless transition, represented by a transition with no event trigger.
A triggerless transition also called a completion transition is triggered implicitly when its
source state has completed its activity.
An event trigger may be polymorphic. If we are specified a family of signals,
then a transition whose trigger event is S can be triggered by S, as well as by any
children of S
Guard condition
A guard condition is rendered as a Boolean expression enclosed in square
brackets and placed after the trigger event. A guard condition is evaluated only after the
trigger event for its transition occurs. Therefore, its possible to have multiple transitions
from the same source state and with the same event trigger, as long as those conditions
dont overlap.
A guard condition is evaluated just once for each transition at the time the event
occurs, but it may be evaluated again if the transition is retriggered. Within the Boolean
expression, we can include conditions about the state of an object.

Although a guard condition is evaluated only once each time its transition
triggers, a change event is potentially evaluated continuously.
Action
An action is an executable atomic computation. Actions may include operation
calls ( to the object that owns the state machine, as well as to other visible objects), the
creation or destruction of another object, or the sending of a signal to an object. The
special notation for sending a signal, the signal name is prefixed with the keyword send
as a visual cue.
An action is atomic, meaning that it cannot be interrupted by an event and
therefore runs to completion. This is in contrast to an activity, which may be interrupted
by other events.
We can explicitly show the object to which a signal is sent by using a
dependency stereotyped as send, whose source is the state and whose target is the object.

1) Explain the four basic principles of modeling.

The four basic principles of modeling are as followsFirst
The choke of what models to create has a profound influence on how a problem
is attacked and how a solution is shaped. We have to choose the models first. The right
models will brilliantly illuminate the most wicked development problems, offering
insight that we simply could not gain otherwise; the wrong models will mislead us,
causing us to focus on irrelevant issues.
In software models, the models we choose, can greatly affect our world view. If
we build a system through the eyes of a database developer, we will likely focus on
entity relationship models that push behavior into triggers and stored procedures. If we
build a system through the eyes of a structured analyst, we will likely end up with
models that are algorithmic-centric, with data flowing from process to process. If we
build a system through the eyes of an object-oriented developer, well end up with a
system whose architecture is centered around a sea of classes and the patterns of
interaction that direct how those classes work together. Any of these approaches might
be right for a given application and development culture, although experience suggests
that the object-oriented view is superior in crafting resilient architectures, even for
systems that might have a large database or computational element. That fact not
withstanding, the point is that each world view leads to a different kind of system, with
different costs and benefits.
Second
Every model may be expressed at different levels of precision.
For ex, if we are building a high rise. sometimes we need a 30,000 foot view, to
help investors visualize its look and feel. Othertimes, we need to get down to the level
of the studs, when theres a tricky pipe run or an unusual structural element.

Like this only, its true with software models. Sometimes, a quick and simple
executable model of the user interface is exactly what we need; at other times, we have
to get down and dirty with the bits, such as when we are specifying cross-system
interfaces or wrestling with networking bottlenecks. In any case, the best kinds of
models are those that let us choose our degree of detail, depending on who is doing the
viewing and why they need to view it. An analyst or an end user will want to focus on
issues of what; a developer will want to focus on issues of how.

Both of these

stakeholders will want to visualize a s ystem at different levels of detail at different

times.
Third
The best models are connected to reality.
For ex, a physical model of a building that doesnt respond in the same way as do
real materials has only limited value; a mathematical model of an aircraft that assumes
only ideal conditions and perfect manufacturing mark some potentially fatal
characteristics of the real aircraft. Its best to have models that have a clear connection
to reality, and where that connection is weak, to know exactly how those models are
divorced from the real world. All models simplify reality; the trick is to be sure that our
simplifications dont mark any important details.
In software, the Achilles heel of structured analysis techniques is the fact that
there is basic disconnect between the analysis model and the systems design model.
Failing to bridge this chasm causes the system as conceived and the system as built to
diverge over time. In object-oriented systems, it is possible to connect all the nearly
independent views of a system into one semantic role.
Fourth
No single model is significant. Every nontrivial systems is best approached
through a small set of nearly independent models.

To understand the architecture of a software system, we need several

complementary and interlocking views; a use case view (exposing the requirements of
the system), a design view (capturing the vocabulary of the problem space and the
solution space), a process view (modeling the distribution of the systems processes and
threads), an implementation view (addressing the physical realization of the system), and
a deployment view (focusing on system engineering issues). Each of these views may
have structural, as well as behavioral aspects. Together, these views represent the
blueprints of software.
Depending on the nature of the system, some models may be more important
than others. For ex, in data-intensive systems, models addressing static design views
will dominate. In GUI-intensive systems, static and dynamic use case views are quite
important. In hard real time systems, dynamic process views tend to be more important.
Finally, in distributed systems, such as one fine in Web-intensive applications,
implementation and deployment models are the most important.
6) Explain the necessary steps to reverse engineer an object diagram
To reverse engineer an object diagram,
-

Choose the target we want to reverse engineer. Typically, well set our context
inside an operation or relative to an instance of one particular class/

Using a tool or simply walking through a scenario, stop execution at a certain

moment in time.

Identify the set of interesting objects that collaborate in that context and render
them in an object diagram

As necessary to understand their semantics, expose these objects states.

As necessary to understand their semantics, identify the links that exist among
these objects.

If our diagram ends up overly complicated, prune it by eliminating objects that

are not germane to the questions about the scenario we need answered. If our

diagram is too simplistic, expand the neighbors of certain interesting objects and
expose each objects state more deeply.
4) Discuss UMLs extensibility mechanisms
The UML provides a standard language for writing software blueprints, but it is
not possible for one closed language to ever be sufficient to express all possible nuances
of all models across all domains across all time. For this reason, the UML is openedended, making it possible for us to extend the language in controlled ways. The UMLs
extensibility mechanisms include:-

Stereotypes

Tagged Values

Constraints
A stereotype extends the vocabulary of the UML, allowing us to create new kinds

of building blocks that are derived from existing ones but are specific to our problem.
For ex., if we are working in a programming language, such as Java or C++, we will
often want to model exceptions. In these languages, exceptions are just classes, although
they are treated in very special ways. Typically, we only want to allow them to be
thrown and caught, nothing else. We can make exceptions first class citizens in our
models meaning that they are treated like basic building blocks by marking them with an
appropriate stereotype, as for the class Overflow.
A tagged value extends the properties of a UML building block, allowing us to
create new information in that elements specification. For ex., if we are working on a
shrink-wrapped product that undergoes many releases overtime, we often want to track
the version and author of certain critical abstractions. Versions and author are not
primitive UML concepts. They can be added to any building block, such as a class, by
introducing new tagged values to that building.

A constraint extends the semantics of a UML building bloc, allowing us to add

new rules or modify existing ones. For ex., we might want to constrain the EventQueue
class so that all additions are done in order. We can add a constraint that explicitly marks
these for the operation add, as shown in the figure.

Collectively, these three extensibility mechanisms allow us to shape and grow the UML
to our projects needs. These mechanisms also let the UML adapt to new software
technology, such as the likely emergence of more powerful distributed programming
languages. We can add new building blocks, modify the specification of existing ones
and even change their semantics. Naturally, its important hat we do so in controlled
ways so that through these extensions, we remain true to the UMLs purpose the
communication of information.
2) How do you model template classes in the UML?
A Template is a parameterized element. In such languages as C++ and Ada, we
can write template classes, each of which defines a family of classes(we can also write
template functions, each of which defines a family or functions). A template includes
slots for classes, objects, and values, and these slots serve as the templates parameters.
We cant use a templates directly; we have to instantiate it first. Instantiation involves
binding these formal template parameters to actual one. For a template class, the result
is a concrete class that can be used just like any ordinary class.
The most common use of template classes is to specify containers that can be
instantiated for specific elements, making them type-safe. For ex., the following C++
code fragment declares a parameterized Map class.

10

template<class item, class Value, int Buckets>

class Map {
public:
virtual Boolean bind (const item&, const Values&);
virtual Boolean is Bound(const item&)const;

};
We might then instantiate this template to map Customer objects to Order objects.
m: Map<customer, Order, 3>;
We can model template classes in the UML as well. In the below figure, we render a
template class just as we do an ordinary class, but with an additional dashed box in the
upper-right corner of the class icon, which lists the template parameters.

The above figure shows that we can model the instantiation of a template class in two
ways. First, we can do so implicitly, by declaring a class whose name provides the
binding. Second, we can do so explicitly, by using a dependency stereotyped as bind,
which specifies that, the source instantiates the target template using actual parameters.

11

3) Explain the significance of aggregation with an example

An important aspect of object oriented design is the concept of Aggregation the
idea that one object can be built from (aggregated from) other objects.
For ex., in a typical computer system, the computer is an aggregation of a CPU, a
graphics card, a soundcard and so on.
We can denote aggregation in UML using the aggregation symbol a diamond at
the end of an association link.

A plain association between two classes represents a structural relationship between

peers, meaning that both classes are conceptually at the same level, no one more
important than the other. Sometimes, we will want to model a whole/part relationship,
in which one class represents a larger thing (the whole). which consists of smaller
things (the parts). This kind of relationship is called aggregation, which represents a
has-a relationship, meaning that an object of the whole has objects of the part.
Aggregation is really just a special kind of association and is specified by adoning a
plain association with an open diamond at the whole end.

12

The meaning of this simple form of aggregation is entirely conceptual.

the open

diamond distinguishes the whole from the part, no more, no less. This means that
simple aggregation doesnot change the meaning of navigation across the association
between the whole and its parts, nor does it link the lifetime of the whole and its parts.
10) Explain the importance of models
A model is a simplification of reality, in which reality is defined in the context of the
system being modeled. In short, a model is an abstraction of a system. A subsystem
represents a partitioning of the elements of a larger system into independent parts: a
model is a portioning of the abstractions that visualize, specify, construct and document
that system. The difference is subtle but important. We decompose a system into
subsystems so that we can develop and deploy these parts somewhat independently: we
partition the abstractions of a system or a subsystem into models so that we can better
understand the thing we are developing and deploying. Just as a complex system such as
an aircraft may have many parts (for ex, the airframe, propulsion, avionics, and
passenger subsystems), those subsystems and the system as a whole may be modeled
from a number of different points of view (such as from the perspective of structural,
dynamic. electrical, and heating/cooling models, for ex).
A model is a special kind of package. Because well rarely need to model
models explicitly, theres no special graphical rendering defined for models in the UML.
Tools need to manipulate models, however, so a tool will typically use package notation
to represent a model as seen by the tool.
As a package, a model owns elements. The models associated with a system or
subsystem completely partition the elements of that system or subsystem, meaning that
every element is owned by exactly one package. Typically, well organize the artifacts
of a system or s subsystem in to a set of non overlapping models, covered by the five
views of software architecture that are described elsewhere.

13

A model (for ex, a process model) may contain so many artifacts (such as active
classes, relationships, and interactions) that in systems of scale, we simply cannot
embrace all those artifacts at once. Think of a view as a projection into a model. For
each model, well have a number of diagrams that exist to give us a peek into the things
owned by the model. A view encompasses a subset of the things owned by a model: a
view typically may not cross model boundaries. As described in the next section, there
are no direct relationships among models, although well find trace relationships among
the elements contained in different models.
The UML does not dictate which models we should use to visualize, specify,
construct, and document a system, although the Rational Unified Process does not
suggest a proven set of models.

14