8/7/2019 MC0069 August 2010 Q & Ans

1/19

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 offunctional 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.

http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Graphical_languagehttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Business_processhttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Component-based_software_engineeringhttp://en.wikipedia.org/wiki/Functional_modelhttp://en.wikipedia.org/wiki/Database_modelhttp://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Modeling_languagehttp://en.wikipedia.org/wiki/Software_engineeringhttp://en.wikipedia.org/wiki/Graphical_languagehttp://en.wikipedia.org/wiki/Artifact_(software_development)http://en.wikipedia.org/wiki/Business_processhttp://en.wikipedia.org/wiki/Programming_languagehttp://en.wikipedia.org/wiki/Component-based_software_engineeringhttp://en.wikipedia.org/wiki/Functional_modelhttp://en.wikipedia.org/wiki/Database_model

8/7/2019 MC0069 August 2010 Q & Ans

2/19

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 problemyou 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 toimplementers.

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 theseabstractions. 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 orsolution. 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 yourclasses.

Provide the attributes and operations that are needed to carry out these

responsibilities for each class.

8/7/2019 MC0069 August 2010 Q & Ans

3/19

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 trivialresponsibilities 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 semanticsand 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 iscalled a relationship.

It is important to understand that although we defined a relationship type, this does notmean 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 existwithout the existence of another

entity as specified within a relationship. The entity type is dependent on another entity

type when each entity of a dependententity (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 notequal to 0 or by a fixed cardinality that is not equal to 0.

8/7/2019 MC0069 August 2010 Q & Ans

4/19

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 havent. Many OO

concepts, such as encapsulation, coupling, and cohesion come from softwareengineering. 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 dont 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 fromclass 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 depictedusing dashed lines with the UML stereotypes of or , 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 boxand 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 theUML. It defines both the data and the behaviour of a structural unit. A class is a templateor 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 inmore maintainable code.

http://www.agiledata.org/essays/objectOrientation101.html#Table1OOTermshttp://www.ambysoft.com/books/theObjectPrimer.htmlhttp://www.agiledata.org/essays/objectOrientation101.html#Table1OOTermshttp://www.ambysoft.com/books/theObjectPrimer.html

8/7/2019 MC0069 August 2010 Q & Ans

5/19

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 beread. This is depicted using a filled triangle, called a direction indicator, an example of

which is shown on the offering ofassociation between the Seminarand 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 isnt 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

http://en.wikipedia.org/wiki/File:KP-UML-Aggregation-20060420.svghttp://en.wikipedia.org/wiki/File:KP-UML-Aggregation-20060420.svg

8/7/2019 MC0069 August 2010 Q & Ans

6/19

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 sameadornments 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 containeressentially, 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 conceptualmodels 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 areassigned 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 indata 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 datamodelers 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 thesituation 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 Agileteams high-level conceptual models are often created as part of yourinitial

requirements envisioning efforts as they are used to explore the high-level static

business structures and concepts. On traditional teams conceptual data models areoften 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 entitytypes, typically referred to simply as entity types, the data attributes describing

those entities, and the relationships between the entities. LDMs are rarely used on

http://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Rhombushttp://www.agiledata.org/essays/umlDataModelingProfile.htmlhttp://www.agilemodeling.com/essays/initialRequirementsModeling.htmhttp://www.agilemodeling.com/essays/initialRequirementsModeling.htmhttp://en.wikipedia.org/wiki/Aggregation_(object-oriented_programming)http://en.wikipedia.org/wiki/Unified_Modeling_Languagehttp://en.wikipedia.org/wiki/Rhombushttp://www.agiledata.org/essays/umlDataModelingProfile.htmlhttp://www.agilemodeling.com/essays/initialRequirementsModeling.htmhttp://www.agilemodeling.com/essays/initialRequirementsModeling.htm

8/7/2019 MC0069 August 2010 Q & Ans

7/19

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 ofa 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. Itis 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 andthe 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 orUML state machine. Also instead of class diagramsObject 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

http://en.wikipedia.org/wiki/Object_orientedhttp://en.wikipedia.org/wiki/Conceptual_modelhttp://en.wikipedia.org/wiki/Programming_codehttp://en.wikipedia.org/wiki/Class_diagram#cite_note-SWA09-0http://en.wikipedia.org/wiki/State_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Object_role_modelinghttp://en.wikipedia.org/wiki/File:BankAccount.jpghttp://en.wikipedia.org/wiki/Object_orientedhttp://en.wikipedia.org/wiki/Conceptual_modelhttp://en.wikipedia.org/wiki/Programming_codehttp://en.wikipedia.org/wiki/Class_diagram#cite_note-SWA09-0http://en.wikipedia.org/wiki/State_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Object_role_modeling

8/7/2019 MC0069 August 2010 Q & Ans

8/19

A Linkis 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 connectedto a central diamond.

An association can be named, and the ends of an association can be adorned with rolenames, ownership indicators, multiplicity, visibility, and other properties. There are five

different types of association. Bi-directional and uni-directional associations are the mostcommon 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 offerscourses", 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 COMcomponents. Over time and across successive releases of UML, the original UML

meaning of components was mostly lost. UML 2 officially changes the essential meaningof 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 designunits 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 specifiedinterfaces. [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 implementedon multiple nodes.

http://en.wikipedia.org/wiki/Object_diagramhttp://en.wikipedia.org/wiki/Association_(object-oriented_programming)http://en.wikipedia.org/wiki/File:UML_role_example.gifhttp://en.wikipedia.org/wiki/Object_diagramhttp://en.wikipedia.org/wiki/Association_(object-oriented_programming)

8/7/2019 MC0069 August 2010 Q & Ans

9/19

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 describingboth 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 classroles, 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 aUML 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.

8/7/2019 MC0069 August 2010 Q & Ans

10/19

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 beingmade 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 arebuilt.

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 youmust 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 shouldbe 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 adepartment 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 bemade 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 UMLdiagramsare 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 isalso logged and especially noted.

In the second step, C#-code is automatically generated based on the UML-model created

in respectivelytool. 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 isintentionally left out in

8/7/2019 MC0069 August 2010 Q & Ans

11/19

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 completesoftware skeleton in

C# based on the generated full UML-diagrams for subsequent reverse engineering by

each tool, generatingtool 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 1above, 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 DataSetfor 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 containsthe 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 keyis 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 aswell 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 instancegoes 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 machinefinishes processing the event instance. A consumed event instance is no longer available

for processing.

http://en.wikipedia.org/wiki/UML_state_machine#cite_note-UML2_2-0http://en.wikipedia.org/wiki/Message_queuehttp://en.wikipedia.org/wiki/UML_state_machine#cite_note-UML2_2-0http://en.wikipedia.org/wiki/Message_queue

8/7/2019 MC0069 August 2010 Q & Ans

12/19

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_cationand 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

modelintensive signal processing applications for embedded systems. A part of this

methodologyhas 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 ofexisting 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 mappingon 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 targetof 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 transitionsare actually identical. However, a local transition doesnt cause exit from the main source

state if the main target state is a substate of the main source. In addition, local state

transition doesnt cause exit and reentry to the target state if the main target is asuperstate of the main source state.

8/7/2019 MC0069 August 2010 Q & Ans

13/19

d) Time and Change Events :- Building models which faithfully represent complexsystems

is a non trivial problem and a prerequisite to the application of formal analysis

techniques. Usually, modelling techniquesare 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 ofmodelling 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-timeprogramming 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 theyhave been last set. All these formalisms represent machines that can perform two kinds of

state changes, time progress steps and actions, where actions correspond toevents, 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 overtime.

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 concreteinstance of that occurrence. For example, Keystroke is an event for the keyboard, but

http://en.wikipedia.org/wiki/File:UML_state_machine_Fig8.png

8/7/2019 MC0069 August 2010 Q & Ans

14/19

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 regardingthat 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 wellas 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 animportant 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 Transitions5. Model Recursive Transitions Only When You Want to Exit and Re-Enter the

State

6. Name Transition Events in Past Tense7. 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

http://www.agilemodeling.com/artifacts/activityDiagram.htmhttp://www.agilemodeling.com/artifacts/activityDiagram.htm

8/7/2019 MC0069 August 2010 Q & Ans

15/19

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 ofdiagram 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 ofstates; 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 reactsdifferently 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.

http://en.wikipedia.org/wiki/Diagramhttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/State_(computer_science)http://en.wikipedia.org/wiki/Abstractionhttp://en.wikipedia.org/wiki/Semantics#Computer_sciencehttp://en.wikipedia.org/wiki/Behaviorhttp://en.wikipedia.org/wiki/Systemhttp://en.wikipedia.org/wiki/Diagramhttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/Computer_sciencehttp://en.wikipedia.org/wiki/State_(computer_science)http://en.wikipedia.org/wiki/Abstractionhttp://en.wikipedia.org/wiki/Semantics#Computer_sciencehttp://en.wikipedia.org/wiki/Behaviorhttp://en.wikipedia.org/wiki/System

8/7/2019 MC0069 August 2010 Q & Ans

16/19

4. Describe the following with suitable examples:

A) Modeling the realization of a Use case :- A relationship is a general term coveringthe 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) thebehavior 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 thatconnects 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 buildingblock 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 diagramthese 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 numberof subclasses.

In order to further describe the behavior of systems, these class diagrams can be

complemented by state diagram orUML state machine. Also instead of class diagrams

Object role modeling can be used if you just want to model the classes and theirrelationships.

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 elementsand diagrams (such as written use cases).

http://en.wikipedia.org/wiki/Object_orientedhttp://en.wikipedia.org/wiki/Conceptual_modelhttp://en.wikipedia.org/wiki/Programming_codehttp://en.wikipedia.org/wiki/State_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Object_role_modelinghttp://en.wikipedia.org/wiki/Object_orientedhttp://en.wikipedia.org/wiki/Conceptual_modelhttp://en.wikipedia.org/wiki/Programming_codehttp://en.wikipedia.org/wiki/State_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/Object_role_modeling

8/7/2019 MC0069 August 2010 Q & Ans

17/19

UML diagrams represent two different views of a system model:

Static (orstructural) view: emphasizes the static structure of the system using

objects, attributes, operations and relationships. The structural view includes classdiagrams and composite structure diagrams.

Dynamic (orbehavioral) view: emphasizes the dynamic behavior of the systemby showing collaborations among objects and changes to the internal states of

objects. This view includes sequence diagrams, activity diagrams and statemachine 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 Microsofts .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

wouldnt 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 broadersystems-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 switchover to it in the near future.

http://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Composite_structure_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/UML_toolhttp://en.wikipedia.org/wiki/XMIhttp://www.agilemodeling.com/essays/initialArchitectureModeling.htmhttp://www.agilemodeling.com/artifacts/componentDiagram.htmhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Class_diagramhttp://en.wikipedia.org/wiki/Composite_structure_diagramhttp://en.wikipedia.org/wiki/Sequence_diagramhttp://en.wikipedia.org/wiki/Activity_diagramhttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/UML_state_machinehttp://en.wikipedia.org/wiki/UML_toolhttp://en.wikipedia.org/wiki/XMIhttp://www.agilemodeling.com/essays/initialArchitectureModeling.htmhttp://www.agilemodeling.com/artifacts/componentDiagram.htm

8/7/2019 MC0069 August 2010 Q & Ans

18/19

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. Itcontains 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 andUML, 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, behaviouralmodel 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 UseCase 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, structuraldimensions 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 displayrelationships such as containment, inheritance and associations.

Object Diagrams: Depict a class or the static structure of a system at a particular

point in time.

8/7/2019 MC0069 August 2010 Q & Ans

19/19

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 executablecomponents 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 UMLelements 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.