Master of Computer Application (MCA) – Semester 2

MC0069 – System Analysis & Design (SAD)

Assignment Set – 1

1. Describe the theory and real time applications of Unified Modeling Language
(UML).
Ans:- The Unified Modeling Language (UML) is a standardized general-purpose
modeling language in the field of software engineering. It is a graphical language for
visualizing, specifying, constructing, and documenting the artifacts of a software-
intensive system. The Unified Modeling Language offers a standard way to write a
system's blueprints, including:

• Conceptual things such as business processes and system functions

• Concrete things such as programming language statements, database schemas,
and
• Reusable software components.

UML offers a mix of functional models, data models, and database models.

1. Introduction.
Object-Oriented Methods and the Unified Modeling Language.
Method and Notation.
Concurrent Applications.
Real-Time Systems and Applications.
Distributed Systems and Applications.

2. Overview of UML Notation.

UML Diagrams.
. Use Case Diagrams.
UML Notation for Classes and Objects.
Class Diagrams.
Interaction Diagrams.
Statechart Diagrams.
Packages.
Concurrent Collaboration Diagrams.
Deployment Diagrams.
UML Extension Mechanisms.
The UML as a Standard.

3. Software Design and Architecture Concepts.

Object-Oriented Concepts.
Information Hiding.
Inheritance.
Active and Passive Objects.
Concurrent Processing.
Cooperation between Concurrent Tasks.
Information Hiding Applied to Access Synchronization.
Monitors.
Design Patterns.
Software Architecture and Component-Based Systems.

4. Concurrent and Distributed System Technology.

Environments for Concurrent Processing.
Runtime Support for Multiprogramming and Multiprocessing Environments.
Task Scheduling.
Operating System Input/Output Considerations.
Client/Server and Distributed System Technology.
World Wide Web Technology.
Distributed Operating System Services.
Middleware.
Common Object Request Broker Architecture (CORBA).
Other Component Technologies.

Transaction Processing Systems.

2. Discuss the common modeling techniques in UML.

Ans:- use classes most commonly to model abstractions that are drawn from the problem
you are trying to solve or from the technology you are using to implement a solution to
that problem. Each of these abstractions is a part of the vocabulary of your system,
meaning that, together, they represent the things that are important to users and to
implementers.

For users, most abstractions are not that hard to identify because, typically, they are
drawn from the things that users already use to describe their system. Techniques such as
CRC cards and use case-based analysis are excellent ways to help users find these
abstractions. For implementers, these abstractions are typically just the things in the
technology that are parts of the solution.

To model the vocabulary of a system,

• Identify those things that users or implementers use to describe the problem or
solution. Use CRC cards and use case-based analysis to help find these
abstractions.
• For each abstraction, identify a set of responsibilities. Make sure that each class is
crisply defined and that there is a good balance of responsibilities among all your
classes.
• Provide the attributes and operations that are needed to carry out these
responsibilities for each class.
To model the distribution of responsibilities in a system,

• Identify a set of classes that work together closely to carry out some behavior.
• Identify a set of responsibilities for each of these classes.
• Look at this set of classes as a whole, split classes that have too many
responsibilities into smaller abstractions, collapse tiny classes that have trivial
responsibilities into larger ones, and reallocate responsibilities so that each
abstraction reasonably stands on its own.
• Consider the ways in which those classes collaborate with one another, and
redistribute their responsibilities accordingly so that no class within a
collaboration does too much or too little.

o model nonsoftware things,

• Model the thing you are abstracting as a class.

• If you want to distinguish these things from the UML's defined building blocks,
create a new building block by using stereotypes to specify these new semantics
and to give a distinctive visual cue.

3. Explain the following in the context of Relationships:

A) Modeling Simple Dependencies :- While entity types describe independent artifacts,

relationship types describe meaningful associations between entity types.
To be precise, the relationship type describes that entities of entity types participating in
the relationship can build a
meaningful association. The actual occurrence of the association between entities is
called a relationship.
It is important to understand that although we defined a relationship type, this does not
mean that every pair of entities
builds a relationship. A relationship type defines only that relationships can occur.
An example of a relationship type is the Employee owns Product. In this example the
relationship type is Owns. The
relationship itself is: The Employee Joe Ward owns a Product, the yellow Telephone,
with the Serial Number 320TS03880.
Dependency refers to a situation in which a particular entity can not meaningfully exist
without the existence of another
entity as specified within a relationship. The entity type is dependent on another entity
type when each entity of a dependent
entity (subtype) depends on the existence of the corresponding parent entity in the super
type.
A mandatory dependency relationship has to be specified by explicitly defining the lower
limit for cardinality that is not
equal to 0 or by a fixed cardinality that is not equal to 0.
B) Modeling Single Inheritance :- To understand OO you need to understand common
object terminology. The critical terms to understand are summarized in Table 1. I
present a much more detailed explanation of these terms in The Object Primer 3/e. Some
of these concepts you will have seen before, and some of them you haven’t. Many OO
concepts, such as encapsulation, coupling, and cohesion come from software
engineering. These concepts are important because they underpin good OO design. The
main point to be made here is that you do not want to deceive yourself – just because you
have seen some of these concepts before, it don’t mean you were doing OO, it just means
you were doing good design. While good design is a big part of object-orientation, there
is still a lot more to it than that.

Single Inheritance

Represents “is a”, “is like”, and “is kind of” relationships. When class “B” inherits from
class “A” it automatically has all of the attributes and operations that “A” implements (or
inherits from other classes)

Associations also exist between use cases in system use case models and are depicted
using dashed lines with the UML stereotypes of <<extend>> or <<include>>, as you see
in.It is also possible to model inheritance between use cases, something that is not shown
in the diagram. The rectangle around the use cases is called the system boundary box
and as the name suggests it delimits the scope of your system – the use cases inside the
rectangle represent the functionality that you intend to implement.

C) Modeling Structural Relationships :- The class is the basic logical entity in the
UML. It defines both the data and the behaviour of a structural unit. A class is a template
or model from which instances or objects are created at run time. When we develop a
logical model such as a structural hierarchy in UML we explicitly deal with classes.
When we work with dynamic diagrams, such as sequence diagrams and collaborations,
we work with objects or instances of classes and their inter-actions at run-time. The
principal of data hiding or encapsulation is based on localisation of effect. A class has
internal data elements that it is responsible for. Access to these data elements should be
through the class's exposed behaviour or interface. Adherence to this principal results in
more maintainable code.
D) Multiplicity and Aggregation :-
Indicator Meaning
0..1 Zero or one
1 One only
0..* Zero or more
1..* One or more
n Only n (where n > 1)
0..n Zero to n (where n > 1)
1..n One to n (where n > 1)

Another option for associations is to indicate the direction in which the label should be
read. This is depicted using a filled triangle, called a direction indicator, an example of
which is shown on the offering of association between the Seminar and Course. This
symbol indicates the association should be read “a seminar is an offering of a course,”
instead of “a course is an offering of a seminar.” Direction indicators should be used
whenever it isn’t clear which way a label should be read. My advice, however, is if your
label is not clear, then you should consider rewording it.

Aggregation

Class diagram showing Aggregation between two classes

Aggregation is a variant of the "has a" or association relationship; aggregation is more
specific than association. It is an association that represents a part-whole or part-of
relationship. As a type of association, an aggregation can be named and have the same
adornments that an association can. However, an aggregation may not involve more than
two classes.

Aggregation can occur when a class is a collection or container of other classes, but
where the contained classes do not have a strong life cycle dependency on the container
—essentially, if the container is destroyed, its contents are not.

In UML, it is graphically represented as a hollow diamond shape on the containing class

end of the tree of lines that connect contained class(es) to the containing class.

4. Write about Common Modeling techniques in Relationships.

Ans:- modeling is the act of exploring data-oriented structures. Like other modeling
artifacts data models can be used for a variety of purposes, from high-level conceptual
models to physical data models. From the point of view of an object-oriented developer
data modeling is conceptually similar to class modeling. With data modeling you identify
entity types whereas with class modeling you identify classes. Data attributes are
assigned to entity types just as you would assign attributes and operations to classes.
There are associations between entities, similar to the associations between classes –
relationships, inheritance, composition, and aggregation are all applicable concepts in
data modeling.

Traditional data modeling is different from class modeling because it focuses solely on
data – class models allow you to explore both the behavior and data aspects of your
domain, with a data model you can only explore data issues. Because of this focus data
modelers have a tendency to be much better at getting the data “right” than object
modelers. However, some people will model database methods (stored procedures,
stored functions, and triggers) when they are physical data modeling. It depends on the
situation of course, but I personally think that this is a good idea and promote the concept
in my UML data modeling profile (more on this later).

• Conceptual data models. These models, sometimes called domain models, are
typically used to explore domain concepts with project stakeholders. On Agile
teams high-level conceptual models are often created as part of your initial
requirements envisioning efforts as they are used to explore the high-level static
business structures and concepts. On traditional teams conceptual data models are
often created as the precursor to LDMs or as alternatives to LDMs.
• Logical data models (LDMs). LDMs are used to explore the domain concepts,
and their relationships, of your problem domain. This could be done for the scope
of a single project or for your entire enterprise. LDMs depict the logical entity
types, typically referred to simply as entity types, the data attributes describing
those entities, and the relationships between the entities. LDMs are rarely used on
 Agile projects although often are on traditional projects (where they rarely seem
to add much value in practice).
• Physical data models (PDMs). PDMs are used to design the internal schema of
a database, depicting the data tables, the data columns of those tables, and the
relationships between the tables. PDMs often prove to be useful on both Agile and
traditional projects and as a result the focus of this article is on physical modeling.

5. Describe the following structural diagrams with relevant examples:

A) Class :- The class diagram is the main building block in object oriented modelling. It
is used both for general conceptual modelling of the systematics of the application, and
for detailed modelling translating the models into programming code. The classes in a
class diagram represent both the main objects and or interactions in the application and
the objects to be programmed. In the class diagram these classes are represented with
boxes which contain three parts: [1]

A class with three sections.

• The upper part holds the name of the class

• The middle part contains the attributes of the class
• The bottom part gives the methods or operations the class can take or undertake

In the system design of a system, a number of classes are identified and grouped together
in a class diagram which helps to determine the statical relations between those objects.
With detailed modeling, the classes of the conceptual design are often split in a number
of subclasses.

In order to further describe the behavior of systems, these class diagrams can be
complemented by state diagram or UML state machine. Also instead of class diagrams
Object role modeling can be used if you just want to model the classes and their
relationships.

B) Object :- A relationship is a general term covering the specific types of logical

connections found on class and object diagrams. UML shows the following relationships:
External links
A Link is the basic relationship among objects. It is represented as a line connecting two
or more object boxes. It can be shown on an object diagram or class diagram. A link is an
instance of an association. In other words, it creates a relationship between two classes.

Association

Class diagram example of association between two classes

An Association represents a family of links. Binary associations (with two ends) are
normally represented as a line, with each end connected to a class box. Higher order
associations can be drawn with more than two ends. In such cases, the ends are connected
to a central diamond.

An association can be named, and the ends of an association can be adorned with role
names, ownership indicators, multiplicity, visibility, and other properties. There are five
different types of association. Bi-directional and uni-directional associations are the most
common ones. For instance, a flight class is associated with a plane class bi-directionally.
Associations can only be shown on class diagrams. Association represents the static
relationship shared among the objects of two classes. Example: "department offers
courses", is an association relation.

C) Component :- The component diagram's main purpose is to show the structural

relationships between the components of a system. In UML 1.1, a component represented
implementation items, such as files and executables. Unfortunately, this conflicted with
the more common use of the term component," which refers to things such as COM
components. Over time and across successive releases of UML, the original UML
meaning of components was mostly lost. UML 2 officially changes the essential meaning
of the component concept; in UML 2, components are considered autonomous,
encapsulated units within a system or subsystem that provide one or more interfaces.
Although the UML 2 specification does not strictly state it, components are larger design
units that represent things that will typically be implemented using replaceable" modules.
But, unlike UML 1.x, components are now strictly logical, design-time constructs. The
idea is that you can easily reuse and/or substitute a different component implementation
in your designs because a component encapsulates behavior and implements specified
interfaces. [Note: The physical items that UML1.x called components are now called
"artifacts" in UML 2. An artifact is a physical unit, such as a file, executable, script,
database, etc. Only artifacts live on physical nodes; classes and components do not have
"location." However, an artifact may manifest components and other classifiers (i.e.,
classes). A single component could be manifested by multiple artifacts, which could be
on the same or different nodes, so a single component could indirectly be implemented
on multiple nodes.
 Master of Computer Application (MCA) – Semester 2
MC0069 – System Analysis & Design (SAD)
Assignment Set – 2

1. Describe the following with respect to Common Modeling Techniques:

A) Modeling Simple Collaborations :- A collaboration diagram describes interactions

among objects in terms of sequenced messages. Collaboration diagrams represent a
combination of information taken from class, sequence, and use case diagrams describing
both the static structure and dynamic behavior of a system.

Basic Collaboration Diagram Symbols and Notations

Class roles

Class roles describe how objects behave. Use the UML object symbol to illustrate class
roles, but don't list object attributes.

Association roles

Association roles describe how an association will behave given a particular situation.
You can draw association roles using simple lines labeled with stereotypes.

• Identify mechanisms and define your system model. The mechanism represents
some function or behavior of a part of the system and modeling is the result of
classroom interactions, interfaces, and other things.
• The mechanism will identify the classes, interfaces, and other collaborations that
connect and complement each other or each other. Then check every relationship
that occurs in the system
• Scan the modeling is if at the time of the search ad is something missing then the
diagram formed / semantic need of repair
• Load the element with the class attribute or operation that may occur.

B) Modeling a logical database schema :- The software will you wake up by using a
UML tool that will have a class which the object will be used continuously so that the
data object allows you to save them in the database . Database that you will often use the
database relational, database or database object berorintasikan used as persistent storage.
UML has the ability to create a model good database logical database schema or database
physically.
With classes held by the UML diagrams will be very easy to form a logical database
design, ER diagrams which differ by only focusing on data diagrams will be able to
describe the behavior or instructions contained in a model. Logical operations is being
made in the form of a database that stores a procedure would be transformed into a
procedure. class diagram which is a superset of the entities of an entity relationship ERD
will be able to describe in detail from a concept of databases and applications that are
built.

The steps used to create a database schema in UML models as follows:

• Identification of classes in your applications in which there are models that

describe the activities in the application.
• UML class diagram depicting the classes that have been identified and then you
must define their own values – values that the details of sfesifikasi database used
in the application.
• Extending classes to establish the details and focusing on the relationship and
cardinality of a database and transform into a structure class.
• Notice the pattern of starting a common database to the intricate patterns, if
necessary you can ordinary these patterns.
• Consider also the behavior of these classes to expand operations necessary for
data access and data integrity. In general, to provide better separation of the
problem, the relevant business rules with the manipulation of these objects should
be encapsulated in a layer above classes these.

Here is an illustration / example of a schematic diagram of the UML model. We will

portray a simple concept classes in a UML class diagram. Here there are several classes
which include: Students, Courses, and Instructors. Each student will follow a course that
is held by each intructur. Each student has a school that the school must have a
department for each course to be followed. While the instructor has a department and
courses that are taught to every student who has been a member for the school.

C) Forward and Reverse Engineering :- The comparison of the different tools will be
made based on the modeling of the chosen web application. A
full UML-model will be created as far as possible with each and every one of the
individual tools. The UMLdiagrams
are created by click-drag-and-drop, complemented with necessary information about
methods and
attributes based on the specification in Table 1. Potential lack of support in any tool for
any functionality is
also logged and especially noted.
In the second step, C#-code is automatically generated based on the UML-model created
in respectively
tool. The resulting code is evaluated based on which, if any, functionality is missing, how
empty methods are
handled and what error messages are generated. As noted above, the main() method is
intentionally left out in
the class diagram in order to examine if the tools automatically generate such a method or
not.
Finally, to test the reverse engineering capabilities of each tool, we wrote a complete
software skeleton in
C# based on the generated full UML-diagrams for subsequent reverse engineering by
each tool, generating
“tool specific” UML-models of the code. Again we compared functionality against the
“true” model and
logged all error messages. Turning to the details in the model specification in Table 1
above, it should be
noted that the number of classes has not been in focus, but the classes are instead mainly
“holders” for the methods, data and return types being investigated. The class “server”
contains the return data type “DataSet”
for instance, which requires a using directive normally not part of auto-generated code.
The intention is to
investigate if each tool automatically adds the necessary using directive or not. The same
class also contains
the attribute “ArrayList”, which in the same way is not a part of the most common using
directives.

2. Define the following terms with suitable examples in the context of Events and
Signals:

a) Kinds of Events :- In the most general terms, an event is an occurrence in time and
space that has significance to the system. Strictly speaking, in the UML specification,[1]
the term event refers to the type of occurrence rather than to any concrete instance of that
occurrence. For example, Keystroke is an event for the keyboard, but each press of a key
is not an event but a concrete instance of the Keystroke event. Another event of interest
for the keyboard might be Power-on, but turning the power on tomorrow at 10:05:36 will
be just an instance of the Power-on event.

An event can have associated parameters, allowing the event instance to convey not
only the occurrence of some interesting incident but also quantitative information
regarding that occurrence. For example, the Keystroke event generated by pressing a key
on a computer keyboard has associated parameters that convey the character scan code as
well as the status of the Shift, Ctrl, and Alt keys.

An event instance outlives the instantaneous occurrence that generated it and might
convey this occurrence to one or more state machines. Once generated, the event instance
goes through a processing life cycle that can consist of up to three stages. First, the event
instance is received when it is accepted and waiting for processing (e.g., it is placed on
the event queue). Later, the event instance is dispatched to the state machine, at which
point it becomes the current event. Finally, it is consumed when the state machine
finishes processing the event instance. A consumed event instance is no longer available
for processing.
b) Signals :- UML Activity Diagrams have Send Signal Action. This action creates an
instance of a Signal from its inputs, and transmits it to the target object, where it may
cause some behavior to be executed as a response to the signal received.
A Signal is a classifier which describes send request - i.e. the data to be transmitted from
a sender of the signal to the receiver. The data carried by a send request are represented
as attributes of the signal.
Complexity in the digital systems integration rises from the heterogeneity of the
components integrated in a chip. The simulation or code generation of such systems
require
to validate methodologies, platforms and technologies to support integration, veri_cation
and programming, of complex systems composed of heterogeneous virtual components.
Several formalisms are needed according to their applicability in order to propose a
framework of formal speci_cation. The uni_cation of these formalisms leads to visually
model
intensive signal processing applications for embedded systems. A part of this
methodology
has come down from the Array-OL language. An application is represented by a graph of
dependences between tasks and arrays. Thanks to the data-parallel paradigm, a task may
iterate the same code on di_erent patterns which tile its depending arrays.
The visual notation we propose uses a UML 2.0 standard proposal. This allows usage of
existing UML 2.0 tools to model an application. A UML pro_le dedicated to Intensive
Signal
Processing with a strong semantics allows automatic code generation, automatic mapping
on SoC architectures for early validation at the higher level of speci_cation.

c) Call Events :- Before UML 2, the only transition semantics in use was the external
transition, in which the main source of the transition is always exited and the main target
of the transition is always entered. UML 2 preserved the "external transition" semantics
for backward compatibility, but introduced also a new kind of transition called local
transition (see Section 15.3.15 in OMG Unified Modeling Language (OMG UML),
Infrastructure Version 2.2). For many transition topologies, external and local transitions
are actually identical. However, a local transition doesn’t cause exit from the main source
state if the main target state is a substate of the main source. In addition, local state
transition doesn’t cause exit and reentry to the target state if the main target is a
superstate of the main source state.
d) Time and Change Events :- Building models which faithfully represent complex
systems
is a non trivial problem and a prerequisite to the application of formal analysis
techniques. Usually, modelling techniques
are applied at early phases of system development and at high abstraction level.
Nevertheless, the need of a unified view of
the various development activities and of their interdependencies
motivated the so called model-based development [49]which heavily relies on the use of
modelling methods and. timed process algebras [45] and timed automata [4]. In
processalgebras, timing is added by a “delay” construct similar to timeout or a wait
construct, as they exist in real-time
programming languages. In Petri nets, minimal and maxima lwaiting times are associated
with states and transitions, and in timed automata, variables called “clocks” increase with
time
progress and can be set (to 0) so that they always measure the time passed since they
have been last set. All these formalisms represent machines that can perform two kinds of
state changes, time progress steps and actions, where actions correspond to
events, that is instantaneous changes of the discrete
state which may depend on time, whereas time steps do not alter the discrete state.
An event is a phenomenon in space and time significant for the modeled system.
An event can appear synchronously or asynchronously.
o synchronous events:
• call event: triggered by call
• exception event: triggered by called object at return
asynchronous events:
• signal event: signal sent by other object
• change event: triggered by side effects on object attributes
• time event: spontaneously triggered by boolean guard over time.

e) Sending and Receiving Events :- In the most general terms, an event is an occurrence
in time and space that has significance to the system. Strictly speaking, in the UML
specification, the term event refers to the type of occurrence rather than to any concrete
instance of that occurrence. For example, Keystroke is an event for the keyboard, but
each press of a key is not an event but a concrete instance of the Keystroke event.
Another event of interest for the keyboard might be Power-on, but turning the power on
tomorrow at 10:05:36 will be just an instance of the Power-on event.

An event can have associated parameters, allowing the event instance to convey not only
the occurrence of some interesting incident but also quantitative information regarding
that occurrence. For example, the Keystroke event generated by pressing a key on a
computer keyboard has associated parameters that convey the character scan code as well
as the status of the Shift, Ctrl, and Alt keys.

f) Transitions :- A transition is a progression from one state to another and will be

triggered by an event that is either internal or external to the entity being modeled. For a
class, transitions are typically the result of the invocation of an operation that causes an
important change in state, although it is important to understand that not all method
invocations will result in transitions. An action is something, in the case of a class it is an
operation, that is invoked by/on the entity being modeled.

1. Name Software Actions Using Implementation Language Naming Conventions

2. Name Actor Actions Using Prose
3. Indicate Entry Actions Only When Applicable For All Entry Transitions
4. Indicate Exit Actions Only When Applicable For All Exit Transitions
5. Model Recursive Transitions Only When You Want to Exit and Re-Enter the
State
6. Name Transition Events in Past Tense
7. Place Transition Labels Near The Source State
8. Place Transitions Labels Based on Transition Direction. To make it easier to
identify which label goes with a transition, place transition labels according to the
following heuristics:

• Above transition lines going left-to-right

• Below transition lines going right-to-left
• Right of transition lines going down
• Left of transition lines going up

3. Describe the following:

A) State machines :- UML state machine diagrams depict the various states that an
object may be in and the transitions between those states. In fact, in other modeling
languages, it is common for this type of a diagram to be called a state-transition diagram
or even simply a state diagram. A state represents a stage in the behavior pattern of an
object, and like UML activity diagrams it is possible to have initial states and final states.
An initial state, also called a creation state, is the one that an object is in when it is first
created, whereas a final state is one in which no transitions lead out of. A transition is a
progression from one state to another and will be triggered by an event that is either
internal or external to the object.

B) Advanced States :-Advanced state diagram is a type of diagram used in computer

science and related fields to describe the behavior of systems. State diagrams require that
the system described is composed of a finite number of states; sometimes, this is indeed
the case, while at other times this is a reasonable abstraction. There are many forms of
state diagrams, which differ slightly and have different semantics.Advanced State
diagrams are used to give an abstract description of the behavior of a system. This
behavior is analyzed and represented in series of events, that could occur in one or more
possible states. Hereby "each diagram usually represents objects of a single class and
track the different states of its objects through the system". a flowchart to an assembly
line in manufacturing because the flowchart describes the progression of some task from
beginning to end (e.g., transforming source code input into object code output by a
compiler). A state machine generally has no notion of such a progression. The door state
machine shown at the top of this article, for example, is not in a more advanced stage
when it is in the "closed" state, compared to being in the "opened" state; it simply reacts
differently to the open/close events. A state in a state machine is an efficient way of
specifying a particular behavior, rather than a stage of processing.
4. Describe the following with suitable examples:

A) Modeling the realization of a Use case :- A relationship is a general term covering

the specific types of logical connections found on class and object diagrams. UML shows
the following relationships:

In UML modeling, a realization relationship is a relationship between two model

elements, in which one model element (the client) realizes (implements or executes) the
behavior that the other model element (the supplier) specifies. A realization is indicated
by a dashed line with a unfilled arrowhead towards the supplier.

Realizations can only be shown on class or component diagrams.

A realization is a relationship between classes, interfaces, components, and packages that

connects a client element with a supplier element. A realization relationship between
classes and interfaces and between components and interfaces shows that the class
realizes the operations offered by the interface.

B) Modeling the realization of an operation :- The class diagram is the main building
block in object oriented modelling. It is used both for general conceptual modelling of the
systematics of the application, and for detailed modelling translating the models into
programming code. The classes in a class diagram represent both the main objects and or
interactions in the application and the objects to be programmed. In the class diagram
these classes are represented with boxes which contain three parts:

A class with three sections.

• The upper part holds the name of the class

• The middle part contains the attributes of the class
• The bottom part gives the methods or operations the class can take or undertake

In the system design of a system, a number of classes are identified and grouped together
in a class diagram which helps to determine the statical relations between those objects.
With detailed modeling, the classes of the conceptual design are often split in a number
of subclasses.

In order to further describe the behavior of systems, these class diagrams can be
complemented by state diagram or UML state machine. Also instead of class diagrams
Object role modeling can be used if you just want to model the classes and their
relationships.

C) Modeling a Mechanism :- It is important to distinguish between the UML model and

the set of diagrams of a system. A diagram is a partial graphic representation of a
system's model. The model also contains documentation that drive the model elements
and diagrams (such as written use cases).
UML diagrams represent two different views of a system model:

• Static (or structural) view: emphasizes the static structure of the system using
objects, attributes, operations and relationships. The structural view includes class
diagrams and composite structure diagrams.
• Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system
by showing collaborations among objects and changes to the internal states of
objects. This view includes sequence diagrams, activity diagrams and state
machine diagrams.

UML models can be exchanged among UML tools by using the XMI interchange format.

5. Describe the following:

A) Modeling the architecture of a system :- deployment diagram depicts a static view
of the run-time configuration of processing nodes and the components that run on those
nodes. In other words, deployment diagrams show the hardware for your system, the
software that is installed on that hardware, and the middleware used to connect the
disparate machines to one another. You want to create a deployment diagram for
applications that are deployed to several machines, for example a point-of-sales
application running on a thin-client network computer which interacts with several
internal servers behind your corporate firewall or a customer service system deployed
using a web services architecture such as Microsoft’s .NET. Deployment diagrams can
also be created to explore the architecture of embedded systems, showing how the
hardware and software components work together. In short, you may want to consider
creating a deployment diagram for all but the most trivial of systems. Nodes can contain
other nodes or software artifacts. The ApplicationServer node contains EJBContainer (a
software node) which in turn contains three software components, a deployment
specification, and a software artifact. The software components use the same notation as
component diagrams (I could have annotated them with their interfaces although that
wouldn’t have added any value in my opinion). Deployment specifications are basically
configuration files, such as an EJB deployment descriptor, which define how a node
should operate.

B) Modeling Systems :- UML, the Universal Modeling Language, was the first language
designed to fulfill the requirement for "universality." However, it is a software-specific
language, and does not support the needs of engineers designing from the broader
systems-based perspective.

Therefore, SysML was created. It has been steadily gaining popularity, and many
companies, especially in the heavily-regulated Defense, Automotive, Aerospace, Medical
Device and Telecomms industries, are already using SysML, or are plannning to switch
over to it in the near future.
However, little information is currently available on the market regarding SysML. Its use
is just on the crest of becoming a widespread phenomenon, and so thousands of engineers
are now beginning to look for training and resources.

The proposed book will provide an introduction to SysML, and instruction on how to
implement it, for all these new users. It is the first available book on SysML in English. It
contains insider information! The author is a member of the SysML working group and
has written sections of the specification. It features a special focus comparing SysML and
UML, and explaining how both can work together.

C) Models and Views :- We need to consider the primary modelling purposes of UML.
These are:

• Business Process Modelling with Use Cases

• Class and Object Modelling
• Behaviour Modelling
• Component Modelling
• Distribution and Deployment Modelling

Each UML model is designed to let analysts, developers and customers view a system
from different perspectives and with varying levels of abstraction. Each diagram will fit
somewhere into these five architectural views representing a distinct problem solution
space. These can be described as the user model view, structural model view, behavioural
model view implementation model view and the environment model view.

The UML user model view encompasses the models which define a solution to a problem
as understood by the client or stakeholders. This view is often also referred to as the Use
Case or scenario view. The main UML model encompassed by this view is the:

• Use Case Diagram: These models depict the functionality required by the system
and the interaction of users and other elements (known as actors) with respect to
the specific solution.

The UML structural view encompasses the models which provide the static, structural
dimensions and properties of the modelled system. This view is often also referred to as
the static or logical view. UML Models applicable to this view include:

• Class Diagrams: These models describe the static structure and contents of a
system using elements such as classes, packages and objects to display
relationships such as containment, inheritance and associations.
• Object Diagrams: Depict a class or the static structure of a system at a particular
point in time.
The UML Implementation View combines the structural and behavioural dimensions of
the solution realisation or implementation. The view is often also referred to as the
component or development view. UML Models applicable to this view include:

• Component Diagrams: These depict the high level organisation and

dependencies of source code components, binary components and executable
components and whether these components exist at compile, link or run time.

D) Traces :- The ability to trace new and changed requirements to their impacted
components provides critical support for managing change in an evolving software
system. Unfortunately numerous studies have shown the difficulties of maintaining links
using traditional traceability methods. Information retrieval techniques can be used to
dynamically generate traces and alleviate the need to maintain explicit links, however
prior work in this area has focused primarily on establishing intra-requirement links or
links between requirements and code. We compare several retrieval techniques for
generating links between requirements, code, and UML models. Tracing to UML
elements provides a higher perspective on the proposed change than would be possible if
links were generated directly to the code and supports the growing trend towards model
driven development. Our experiment returned better results for establishing links to UML
artifacts than to code, suggesting the usefulness of establishing links to code via UML
artifacts. We conclude the paper by discussing the implications of this approach for
managing the evolution of a software system.