7/31/2019 Mc0069 Paper 2

1/20

1. Explain the four kinds of relationships in UML.

UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying,

constructing and documenting the components of software and non software systems. Here the

Visualization is the most important part which needs to be understood and remembered by heart.

UML notations are the most important elements in modeling. Efficient and appropriate use of notations

is very important for making a complete and meaningful model. The model is useless unless its

purpose is depicted properly.

So learning notations should be emphasized from the very beginning. Different notations are available

for things and relationships. And the UML diagrams are made using the notations of things and

relationships. Extensibility is another important feature which makes UML more powerful and flexible.

The chapter describes the UML Basic Notations in more details. This is just an extension to the UML

buildling block section I have discussed in previous chapter.

Structural Things:

Graphical notations used in structural things are the most widely used in UML. These are considered as

the nouns of UML models. Following are the list of structural things.

Classes

Interface

Collaboration

Use case

Active classes

Components

Nodes

Class Notation:

UML class is represented by the diagram shown below. The diagram is divided into four parts.

The top section is used to name the class.

The second one is used to show the attributes of the class.

The third section is used to describe the operations performed by the class.

The fourth section is optional to show any additional components.

Classes are used to represent objects. Objects can be anything having properties and responsibility.

7/31/2019 Mc0069 Paper 2

2/20

Object Notation:

The objectis represented in the same way as the class. The only difference is the name which is

underlined as shown below.

As object is the actual implementation of a class which is known as the instance of a class. So it has the

same usage as the class.

Interface Notation:

Interface is represented by a circle as shown below. It has a name which is generally written below the

circle.

Interface is used to describe functionality without implementation. Interface is the just like a template

where you define different functions not the implementation. When a class implements the interface it

also implements the functionality as per the requirement.

Collaboration Notation:

Collaboration is represented by a dotted eclipse as shown below. It has a name written inside theeclipse.

7/31/2019 Mc0069 Paper 2

3/20

Collaboration represents responsibilities. Generally responsibilities are in a group.

Use case Notation:

Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.

Use case is used to capture high level functionalities of a system.

Actor Notation:

An actor can be defined as some internal or external entity that interacts with the system.

Actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation:

Initial state is defined to show the start of a process. This notation is used in almost all diagrams.

7/31/2019 Mc0069 Paper 2

4/20

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation:

Final state is used to show the end of a process. This notation is also used in almost all diagrams to

describe the end.

The usage of Final State Notation is to show the termination point of a process.

Active class Notation:

Active class looks similar to a class with a solid border. Active class is generally used to describe

concurrent behaviour of a system.

Active class is used to represent concurrency in a system.

Component Notation:

A component in UML is shown as below with a name inside. Additional elements can be added

wherever required.

Component is used to represent any part of a system for which UML diagrams are made.

Node Notation:

A node in UML is represented by a square box as shown below with a name. A node represents a

physical component of the system.

7/31/2019 Mc0069 Paper 2

5/20

Node is used to represent physical part of a system like server, network etc.

Behavioural Things:

Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to

represent the dynamic part of software and non software systems. These features include interactions

andstate machines.

Interactions can be of two types:

Sequential (Represented by sequence diagram)

Collaborative (Represented by collaboration diagram)

Interaction Notation:

Interaction is basically message exchange between two UML components. The following diagram

represents different notations used in an interaction.

7/31/2019 Mc0069 Paper 2

6/20

Interaction is used to represent communication among the components of a system.

State machine Notation:

State machine describes the different states of a component in its life cycle. The notations are described

in the following diagram.

State machine is used to describe different states of a system component. The state can be active, idle

or any other depending upon the situation.

Grouping Things:

Organizing the UML models are one of the most important aspects of the design. In UML there is only

one element available for grouping and that is package.

Package Notation:

Package notation is shown below and this is used to wrap the components of a system.

Annotational Things:

In any diagram explanation of different elements and their functionalities are very important. So UML

has notes notation to support this requirement.

7/31/2019 Mc0069 Paper 2

7/20

Note Notation:

This notation is shown below and they are used to provide necessary information of a system.

Relationships

A model is not complete unless the relationships between elements are described properly. The

Relationship gives a proper meaning to an UML model. Following are the different types of

relationships available in UML.

Dependency

Association

Generalization

Extensibility

Dependency Notation:

Dependency is an important aspect in UML elements. It describes the dependent elements and the

direction of dependency.

Dependency is represented by a dotted arrow as shown below. The arrow head represents the

independent element and the other end the dependent element.

Dependency is used to represent dependency between two elements of a system.

Association Notation:

Association describes how the elements in an UML diagram are associated. In simple word it describes

how many elements are taking part in an interaction.

Association is represented by a dotted line with (without) arrows on both sides. The two ends represent

two associated elements as shown below. The multiplicity is also mentioned at the ends (1, * etc) to

show how many objects are associated.

7/31/2019 Mc0069 Paper 2

8/20

Association is used to represent the relationship between two elements of a system.

Generalization Notation:

Generalization describes the inheritance relationship of the object oriented world. It is parent and child

relationship.

Generalization is represented by an arrow with hollow arrow head as shown below. One end represents

the parent element and the other end child element.

Generalization is used to describe parent-child relationship of two elements of a system.

Extensibility Notation:

All the languages (programming or modeling) have some mechanism to extend its capabilities like

syntax, semantics etc. UML is also having the following mechanisms to provide extensibility features.

Stereotypes (Represents new elements)

Tagged values (Represents new attributes)

Constraints (Represents the boundaries)

Extensibility notations are used to enhance the power of the language. It is basically additional

elements used to represent some extra behaviour of the system. These extra behaviours are not covered

by the standard available notations.

2. What are the considerations that should be taken care to model the distribution of responsibilities in

a system?

7/31/2019 Mc0069 Paper 2

9/20

Introduction

Information security means protecting information and information systems from unauthorized access,

use, disclosure, disruption, modification, or destruction.

Information Security managementis a process of defining the security controls in order to protect the

information assets.

Security Program

The first action of a management program to implement information security is to have a security

program in place

Security Program Objectives

Protect the company and its assets.

Manage Risks by Identifying assets, discovering threats and estimating the risk

Provide direction for security activities by framing of information security policies, procedures,

standards, guidelines and baselines Information Classification

Security Organization and

Security Education

Security Management Responsibilities

Determining objectives, scope, policies, priorities, standards, and strategies.

Determine actual goals that are expected to be accomplished from a security program

Evaluate business objectives, security risks, user productivity, and functionality requirements.

Define steps to ensure that all the above are accounted for and properly addressed

Approaches to Build a Security Program

Top-Down Approach

o The initiation, support, and direction comes from the top management and work their

way through middle management and then to staff members.

o Treated as the best approach.

o Ensures that the senior management who are ultimately responsible for protecting the

company assets is driving the program.

Bottom-Up Approach

o The lower-end team comes up with a security control or a program without proper

management support and direction.

o It is less effective and doomed to fail

Security Controls

Security Controls can be classified into three categories

Administrative Controls which include

Developing and publishing of policies, standards, procedures, and guidelines.

Screening of personnel. Conducting security-awareness training and

Implementing change control procedures.

Technical or Logical Controls which include

7/31/2019 Mc0069 Paper 2

10/20

Implementing and maintaining access control mechanisms.

Password and resource management.

Identification and authentication methods

Security devices and

Configuration of the infrastructure.

Physical Controls which include

Controlling individual access into the facility and different departments

Locking systems and removing unnecessary floppy or CD-ROM drives

Protecting the perimeter of the facility

Monitoring for intrusion and

Environmental controls.

Security Note: It is the responsibility of the information owner

(usually a Sr. executive within

the management group or head of a specific dept) to protect the

data and is the due care

(liable by the court of law) for any kind of negligence

The Elements of Security

Vulnerability

It is a software, hardware, or procedural weakness that may provide an attacker the open door

he is looking for to enter a computer or network and have unauthorized access to resources

within the environment.

Vulnerability characterizes the absence or weakness of a safeguard that could be exploited.

E.g.: a service running on a server, unpatched applications or operating system software,

unrestricted modem dial-in access, an open port on a firewall, lack of physical security etc.

Threat

Any potential danger to information or systems.

A threat is a possibility that someone (person, s/w) would identify and exploit the vulnerability.

The entity that takes advantage of vulnerability is referred to as a threat agent. E.g.: A threat

agent could be an intruder accessing the network through a port on the firewall

Risk

Risk is the likelihood of a threat agent taking advantage of vulnerability and the correspondingbusiness impact.

Reducing vulnerability and/or threat reduces the risk.

E.g.: If a firewall has several ports open, there is a higher likelihood that an intruder will use

one to access the network in an unauthorized method.

Exposure

An exposure is an instance of being exposed to losses from a threat agent.

Vulnerability exposes an organization to possible damages.

E.g.:If password management is weak and password rules are not enforced, the company is

exposed to the possibility of having users' passwords captured and used in an unauthorizedmanner.

Countermeasure or Safeguard

7/31/2019 Mc0069 Paper 2

11/20

It is an application or a s/w configuration or h/w or a procedure that mitigates the risk.

E.g.: strong password management, a security guard, access control mechanisms within an

operating system, the implementation of basic input/output system (BIOS) passwords, and

security-awareness training.

The Relation Between the Security Elements

Example: If a company has antivirus software but does not keep the virus signatures up-to-date,

this is vulnerability. The company is vulnerable to virus attacks.

The threat is that a virus will show up in the environment and disrupt productivity.

The likelihood of a virus showing up in the environment and causing damage is the risk.

If a virus infiltrates the company's environment, then vulnerability has been exploited and the

company is exposed to loss.

The countermeasures in this situation are to update the signatures and install the antivirus

software on all computers

Threat Agent gives rise to Threat exploitsVulnerability leads to

Risk

can damageAssets and causes an Exposure can be counter measured

by Safeguard

directly effects Threat Agent

3. Explain dependency in detail and also how is it different from dependency.

Dependency injection is an expression coined in Martin Fowler's articleInversion of Control

Containers and the Dependency Injection Pattern. This is an nice article, but it misses some of the

benefits of dependency injection containers. Therefore I also disagree with the articles conclusion, but

more on that in a different text.

Dependency injection is a style of object configuration in which an objects fields and collaborators areset by an external entity. In other words objects are configured by an external entity. Dependency

injection is an alternative to having the object configure itself. This may sound a bit abstract so let's

look at a simple example:

public class MyDao {

protected DataSource dataSource =

new DataSourceImpl("driver", "url", "user", "password");

//data access methods...

public Person readPerson(int primaryKey) {...}

}

This DAO (Data Access Object) class, MyDao, needs a javax.sql.DataSource instance in order to

obtain database connections. The database connections are used to read from and write data to the

database, for instance Person objects.

Notice how the MyDao class instantiates a DataSourceImpl instance as its needed DataSource. The

fact that the MyDao class needs a DataSource implemenation means that it "depends" on it. It cannot

carry out its work without a DataSource implementation. Therefore, MyDao has a "dependency" on the

DataSource interface and on some implementation of it.

The MyDao class itself instantiates a DataSourceImpl as its DataSource implementation. Therefore the

MyDao class is said to "satisfy its own dependencies". When a class satisfies its own dependencies it

http://www.martinfowler.com/articles/injection.htmlhttp://www.martinfowler.com/articles/injection.htmlhttp://www.martinfowler.com/articles/injection.htmlhttp://www.martinfowler.com/articles/injection.htmlhttp://www.martinfowler.com/articles/injection.html

7/31/2019 Mc0069 Paper 2

12/20

automatically also depends on the classes it satisfies the dependencies with. In this case MyDao now

also depends on DataSourceImpl, and on the four hardcoded string values passed as parameter to the

DataSourceImpl constructor. You cannot use a different value for the four strings, nor use a different

implementation of the DataSource interface, without changing the code.

As you can see, when a class satisfies its own dependencies it becomes inflexible with regards to these

dependencies. This is bad. This means, that if you need to change the dependencies you will have to

change the code. In this example, if you need to use a different database, you will need to change the

MyDao class. If you have many DAO classes implemented like this you will need to change them all.

In addition, you cannot unit test the MyDao class using a mock DataSource implementation. You can

only use the DataSourceImpl. It doesn't take much brains to figure out that this is a bad idea.

Let's change the design a little:

public class MyDao {

protected DataSource dataSource = null;

public MyDao(String driver, String url, String user, String

password){

this.dataSource = new DataSourceImpl(driver, url, user,

password);

}

//data access methods...

public Person readPerson(int primaryKey) {...}

}

Notice how the DataSourceImpl instantiation is moved into a constructor. The constructor takes four

parameters which are the four values needed by the DataSourceImpl. Though the MyDao class still

depends on these four values, it no longer satisfies these dependencies itself. They are provided by

whatever class creating a MyDao instance. The values are said to be "injected" into the MyDao

constructor. Hence the term "dependency injection". It is now possible to change the database driver,

url, user name and password used by the MyDao class, without changing the MyDao class.

Dependency injection is not restricted to constructors. You can also inject dependencies using setter

methods, or directly into public fields.

The MyDao class can still be made more independent. It still depends on both the DataSource interfaceand the DataSourceImpl class. There is no need for it to depend on more than the DataSource interface.

This can be achieved by injecting a DataSource into the constructor instead of the four string

parameters. Here is how that looks:

public class MyDao {

protected DataSource dataSource = null;

public MyDao(DataSource dataSource){

this.dataSource = dataSource;

}

//data access methods...

public Person readPerson(int primaryKey) {...}

7/31/2019 Mc0069 Paper 2

13/20

}

Now the MyDao class no longer depends on the DataSourceImpl class, or the four strings needed by

the DataSourceImpl constructor. You can now inject any DataSource implementation into the MyDao

constructor.

Dependency Injection Chaining

The example in the previous section is a bit simplified, and doesn't do dependency injection full

justice. You may argue that the dependency is now moved from the MyDao class to each client using

the MyDao class. Clients now have to know about some DataSource implementation to be able to

inject it into the MyDao constructor. Here is an example:

public class MyBizComponent{

public void changePersonStatus(Person person, String status){

MyDao dao = new MyDao(

new DataSourceImpl("driver", "url", "user",

"password"));

Person person = dao.readPerson(person.getId());

person.setStatus(status);

dao.update(person);

}

}

As you can see the MyBizComponent now depends on the DataSourceImpl class and the four strings

needed by its constructor. This is even worse than having the MyDao depend on them because the

MyBizComponent now depends on classes and information that it isn't using itself. Furthermore theDataSourceImpl and constructor parameter belongs to a different abstraction layer. A layer below the

MyBizComponent - the DAO layer.

The solution is to continue the dependency injection all the way up through the layers. The

MyBizComponent should only depend on a MyDao instance. Here is how that looks:

public class MyBizComponent{

protected MyDao dao = null;

public MyBizComponent(MyDao dao){this.dao = dao;

}

public void changePersonStatus(Person person, String status){

Person person = dao.readPerson(person.getId());

person.setStatus(status);

dao.update(person);

}

}

Again the dependency, MyDao, is injected into the class via the constructor. Now the

MyBizComponent only depends on the MyDao class. If MyDao was an interface you could even

switch implementation without the MyBizComponent knowing about it.

7/31/2019 Mc0069 Paper 2

14/20

This dependency injection pattern is continued all the way up the layers of your application, from the

lowest data accessing layers up to the user interface (if any).

4. Define stereotype, tagged value and constraint.

Stereotype is a profile class which defines how an existing metaclass may be extendedas part of a profile. It enables the use of a platform or domain specific terminology ornotation in place of, or in addition to, the ones used for the extended metaclass.

A stereotype cannot be used by itself, but must always be used with one of the metaclassesit extends. Stereotype cannot be extended by another stereotype.

A stereotype uses the same notation as a class, with the keyword stereotype shownbefore or above the name of the stereotype. Stereotype names should not clash withkeyword names for the extended model element.

Servlet Stereotype extends Component.

Stereotype can change the graphical appearance of the extended model element by usingattached icons represented by Image class.

Stereotype Servlet with attached custom icon.

Actor is extended by stereotype Web Client with attached custom icon.

Because stereotype is a class, it may have properties. Properties of a stereotype arereferred to as tag definitions. When a stereotype is applied to a model element, the valuesof the properties are referred to as tagged values.

Device extended by Server stereotype with tag definitions and custom icon.

Tagged Value:

UML 1.x defined tagged value as one of UML extensibility mechanisms permitting arbitraryinformation (which could not be expressed by UML) to be attached to models. Taggedvalue is a keyword-value pair that may be attached to any kind of model element.

The keyword is called a tag. Each tag represents a particular kind of property applicable toone or many kinds of model elements. Both the tag and the value are usually encoded asstrings though UML tool allow to use other data types for values.

Tagged value specification in UML 1.x has the formname = value

where name is the name of a tag or metamodel attribute and value is an arbitrary string thatdenotes its value. For example,

{author="Joe Smith", deadline=31-March-1997, status=analysis}

Boolean tags frequently have the form isQuality, where quality is some condition that maybe true orfalse. In these cases, the form "quality" may usually appear by itself, without avalue and defaulting to true. For example, {abstract} is the same as {isAbstract=true}. Tospecify a value offalse, omit the name completely. Tags of other types require explicitvalues.

7/31/2019 Mc0069 Paper 2

15/20

Tagged value (as well as metamodel attribute) is displayed as a comma delimitedsequence of properties inside a pair of curly braces "{" and "}".

Stereotype Computer appliedusing "traditional" tag values notation.

In UML 1.3 tagged values could extend a model element without requiring the presence ofa stereotype. In UML 1.4, this capability, although still supported, was deprecated, to beused only for backward compatibility reasons.

Since UML 2.0, a tagged value can only be represented as an attribute defined on astereotype. Therefore, a model element must be extended by a stereotype in order to beextended by tagged values. To support compatibility with the UML 1.3 some UML tools canautomatically define a stereotype to which "unattached" attributes (tagged values) will beattached.

Tag values could be shown in class compartment under stereotype name. An additionalcompartment is required for each applied stereotype whose values are to be displayed.

Each such compartment is headed by the name of the applied stereotype in guillemets.

Stereotype Computer applied with tag values in compartment

Tag values could be shown in attached comment under stereotype name.

Stereotype Computer applied with tag values in comment note

When displayed in compartments or in a comment symbol, each name-value pair shouldappear on a separate line.

Constraint:

A constraint is used to express a condition, restriction orassertion related to some ofthe semantics of a model element.

Constraint is a condition which must evaluate to true by a correct design of the system.For example, bank account balance constraint could be expressed as:{balance >= 0}

Constraint in UML is usually written in curly braces using any computer or natural languageincluding English, so that it might look as:

{account balance is positive}

UML prefers OCL as constraint language.

5. What is the main advantage of modeling a system at different levels of abstraction by presenting

diagrams with different levels of detail?

Abstraction is a process by which higherconcepts are derived from the usage and classification of

literal ("real" or "concrete") concepts,first principles, or other methods. "An abstraction" is the product

of this process a concept that acts as a super-categorical noun for all subordinate concepts, and

connects any related concepts as agroup, field, orcategory.

Abstractions may be formed by reducing theinformation content of aconcept or an observable

phenomenon, typically to retain only information which is relevant for a particular purpose. For

http://en.wikipedia.org/wiki/Hierarchyhttp://en.wikipedia.org/wiki/First_principlehttp://en.wikipedia.org/wiki/First_principlehttp://en.wikipedia.org/wiki/Informationhttp://en.wikipedia.org/wiki/Informationhttp://en.wikipedia.org/wiki/Concepthttp://en.wikipedia.org/wiki/Concepthttp://en.wikipedia.org/wiki/Phenomenonhttp://en.wikipedia.org/wiki/Hierarchyhttp://en.wikipedia.org/wiki/First_principlehttp://en.wikipedia.org/wiki/Informationhttp://en.wikipedia.org/wiki/Concepthttp://en.wikipedia.org/wiki/Phenomenon

7/31/2019 Mc0069 Paper 2

16/20

example, abstracting a leather soccer ball to the more general idea of aball retains only the information

on general ball attributes and behavior, eliminating the other characteristics of that particular ball

Origins

Thinking in abstractions is considered to be one of the key traits inmodern human behaviour, which is

believed to have developed between 50,000 and 100,000 years ago, probably before the modern human

exodus from Africa. Its development is likely to have been closely connected with the development of

human language, which (whether spoken or written) appears to both involve and facilitate abstract

thinking.

The oldest known physical representations identified as symbols for abstract concepts are abstract

engravings found on two pieces ofochre inBlombos Cave, South Africa, in 2001. These have been

dated to about 77,000 years ago, during theMiddle Stone Age.[

6. Explain the process of modeling a logical database schema?

A logical data model (LDM) in systems engineering is a representation of an organization's data,

organized in terms of entities and relationships and is independent of any particular data management

technology.

Overview

Logical data models represent the abstract structure of some domain of information. They are often

diagrammatic in nature and are most typically used in business processes that seek to capture things of

importance to an organization and how they relate to one another. Once validated and approved, the

logical data model can become the basis of aphysical data modeland inform the design of a database.

Logical data models should be based on the structures identified in a precedingconceptual data model,

since this describes the semantics of the information context, which the logical model should also

reflect. Even so, since the logical data model anticipates implementation on a specific computing

system, the content of the logical data model is adjusted to achieve certain efficiencies.

The term 'Logical Data Model' is sometimes used as a synonymof'Domain Model' or as an alternative

to the domain model. While the two concepts are closely related, and have overlapping goals, a domain

model is more focused on capturing the concepts in the problem domain rather than the structure of the

data associated with that domain.

History

http://en.wikipedia.org/wiki/Ballhttp://en.wikipedia.org/wiki/Ballhttp://en.wikipedia.org/wiki/Modern_human_behaviourhttp://en.wikipedia.org/wiki/Modern_human_behaviourhttp://en.wikipedia.org/wiki/Recent_African_origin_of_modern_humanshttp://en.wikipedia.org/wiki/Languagehttp://en.wikipedia.org/wiki/Symbolhttp://en.wikipedia.org/wiki/Ochrehttp://en.wikipedia.org/wiki/Blombos_Cavehttp://en.wikipedia.org/wiki/Blombos_Cavehttp://en.wikipedia.org/wiki/Middle_Stone_Agehttp://en.wikipedia.org/wiki/Middle_Stone_Agehttp://en.wikipedia.org/wiki/Abstraction#cite_note-0http://en.wikipedia.org/wiki/Abstraction#cite_note-0http://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Physical_data_modelhttp://en.wikipedia.org/wiki/Physical_data_modelhttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Synonymhttp://en.wikipedia.org/wiki/Synonymhttp://en.wikipedia.org/wiki/Domain_modelhttp://en.wikipedia.org/wiki/Domain_modelhttp://en.wikipedia.org/wiki/Domain_modelhttp://en.wikipedia.org/wiki/File:4-2_ANSI-SPARC_three_level_architecture.svghttp://en.wikipedia.org/wiki/File:4-2_ANSI-SPARC_three_level_architecture.svghttp://en.wikipedia.org/wiki/Ballhttp://en.wikipedia.org/wiki/Modern_human_behaviourhttp://en.wikipedia.org/wiki/Recent_African_origin_of_modern_humanshttp://en.wikipedia.org/wiki/Languagehttp://en.wikipedia.org/wiki/Symbolhttp://en.wikipedia.org/wiki/Ochrehttp://en.wikipedia.org/wiki/Blombos_Cavehttp://en.wikipedia.org/wiki/Middle_Stone_Agehttp://en.wikipedia.org/wiki/Abstraction#cite_note-0http://en.wikipedia.org/wiki/Systems_engineeringhttp://en.wikipedia.org/wiki/Physical_data_modelhttp://en.wikipedia.org/wiki/Conceptual_data_modelhttp://en.wikipedia.org/wiki/Synonymhttp://en.wikipedia.org/wiki/Domain_model

7/31/2019 Mc0069 Paper 2

17/20

The ANSI/SPARC three level architecture, which "shows that a data model can be an external model

(or view), a conceptual model, or a physical model. This is not the only way to look at data models, but

it is a useful way, particularly when comparing models".[1]

When ANSI first laid out the idea of a logical schema in 1975,[2] the choices were hierarchicaland

network. The relational model where data is described in terms of tables and columns had just been

recognized as a data organization theory but no software existed to support that approach. Since that

time, an object-oriented approach to data modelling where data is described in terms of classes,

attributes, and associations has also been introduced.

Logical data model topics

Reasons for building a logical data model

Helps common understanding of business data elements and requirements

Provides foundation for designing a database

Facilitates avoidance ofdata redundancy and thus prevent data & business transaction

inconsistency

Facilitates data re-use and sharing

Decreases development and maintenance time and cost

Confirms a logicalprocess model and helps impact analysis.

7. Explain the concept of sequencing.

# In genetics and biochemistry, sequencing means to determine the primary structure (or primary

sequence) of an unbranched biopolymer. Sequencing results in a symbolic linear depiction known as a

sequence which succinctly summarizes much of the atomic-level structure of the sequenced molecule.

en.wikipedia.org/wiki/Sequencing

# the procedure of determining the order of amino acids in the polypeptide chain of a protein (protein

sequencing) or of nucleotides in a DNA section comprising a gene (gene sequencing)

en.wiktionary.org/wiki/sequencing

# sequence - serial arrangement in which things follow in logical order or a recurrent pattern; "the

sequence of names was alphabetical"; "he invented a technique to determine the sequence of base pairs

in DNA"

# sequence - a following of one thing after another in time; "the doctor saw a sequence of patients"

# sequence - film consisting of a succession of related shots that develop a given subject in a movie

# sequence - arrange in a sequence

# sequence - succession: the action of following in order; "he played the trumps in sequence"# sequence - determine the order of constituents in; "They sequenced the human genome"

# sequence - several repetitions of a melodic phrase in different keys

wordnetweb.princeton.edu/perl/webwn

# Sequence - In mathematics, a sequence is an ordered list of objects (or events). Like a set, it contains

members (also called elements or terms), and the number of terms (possibly infinite) is called the

length of the sequence. ...

8. Explain the different components of states with reference to state machines

tate Machines:

http://en.wikipedia.org/wiki/Three_schema_approachhttp://en.wikipedia.org/wiki/Logical_data_model#cite_note-MW99-0http://en.wikipedia.org/wiki/Logical_data_model#cite_note-1http://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Data_redundancyhttp://en.wikipedia.org/wiki/Data_redundancyhttp://en.wikipedia.org/wiki/Process_modelhttp://en.wikipedia.org/wiki/Process_modelhttp://en.wikipedia.org/wiki/Impact_analysishttp://en.wikipedia.org/wiki/Three_schema_approachhttp://en.wikipedia.org/wiki/Logical_data_model#cite_note-MW99-0http://en.wikipedia.org/wiki/Logical_data_model#cite_note-1http://en.wikipedia.org/wiki/Relational_modelhttp://en.wikipedia.org/wiki/Object-oriented_analysis_and_designhttp://en.wikipedia.org/wiki/Data_redundancyhttp://en.wikipedia.org/wiki/Process_modelhttp://en.wikipedia.org/wiki/Impact_analysis

7/31/2019 Mc0069 Paper 2

18/20

A state machine is a behavior that specifies the sequences of states an object goes throughduring its lifetime in response to events, together with its responses to those events. Weuse state machines to model the dynamic aspects of a system. The state of an object is acondition or situation during the life of an object during which it satisfies some condition,performs some activity, or waits for some events.

An event is the specification of a significant occurrence that has a location in time andspace. In the context of state machines, an event is an occurrence of a stimulus that cantrigger a state transition.

A transition is a relationship between two states indicating that an object is the first state willperform certain actions and enter the second state when a specified non atomic executionwithin a state machine.

A action is an executable atomic computation that results in a change in state of the modelor the return of a value.

A state has several parts:

Name- A textual string that distinguishes the state from other states; a state may beanonymous, meaning that it has no name.

Entry/Exit actions-Actions executed on entering and ending the state, respectively.

Internal transitions- Transitions that are handled without causing a change in state.

Substates- The nested structure of a state, involving disjoint or concurrent substates.

Deferred event- A list of events that are not handled in that state but, rather, are postponed

and queued for handling by the object in another state.

9. Explain behavioral aspects of collaboration with an example.

Behavior-driven development (orBDD) is anagile software development technique devised by Dan

North[1] as a response to the issues encountered teaching test-driven development:[1]

Where to start in the process What to test and what not to test

How much to test in one go

What to call the tests

How to understand why a test fails

At the heart of BDD is a rethinking of the approach to unit testing and acceptance testing: unit test

names are whole sentences starting with the word "should" and they are written in order of business

value. Acceptance tests are written using the standard agile framework of a User story: "As a [role] I

want [feature] so that [benefit]". Acceptance criteria are written in terms of scenarios and implemented

as classes: Given [initial context], when [event occurs], then [ensure some outcomes].[1]

BDD encourages collaboration among developers,QA and non-technical or business participants in a

software project. It has evolved over several years.[2]

http://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/User_storyhttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Quality_assurancehttp://en.wikipedia.org/wiki/Quality_assurancehttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-evolution-1http://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/User_storyhttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Quality_assurancehttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-evolution-1

7/31/2019 Mc0069 Paper 2

19/20

On the "Agile specifications, BDD and Testing eXchange" in November 2009 in London, Dan North[3]

gave the following description of BDD:

BDD is a second-generation, outsidein, pull-based, multiple-stakeholder, multiple-scale, high-

automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting

in the delivery of working, tested software that matters.

BDD focuses on obtaining a clear understanding of desired software behavior through discussion with

stakeholders. It extends TDD by writingtest cases in a natural language that non-programmers can

read. Behavior-driven developers use their native language in combination with the ubiquitous

language ofdomain-driven design to describe the purpose and benefit of their code. This allows the

developers to focus on why the code should be created, rather than the technical details, and minimizes

translation between the technical language in which the code is written and the domain language

spoken by the business, users, stakeholders, project managers, etc.

Dan North created the first ever BDD framework, JBehave[1], followed by a story-level BDD

framework for Ruby called RBehave[4] which was later integrated into the RSpec project.[5] He also

worked with David Chelimsky, Aslak Hellesy and others to develop RSpec and also to write "The

RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends". The first story-based framework in RSpec was later replaced byCucumbermainly developed by Aslak Hellesy.

In 2008, Chris Matts, who was involved in the first discussions around BDD, came up with the idea of

Feature Injection, allowing BDD to cover the analysis space and provide a full treatment of the

software lifecycle from vision through to code and release.

Contents

1 BDD practices

2 Outsidein 3 Application examples in the Gherkin language

o 3.1 Scenario 1: Refunded items should be returned to stock

o 3.2 Scenario 2: Replaced items should be returned to stock

4 Programmer-domain examples and behavior

5 Using mocks

6 References

7 External links

BDD practices

The practices of BDD include:

Establishing the goals of different stakeholders required for a vision to be implemented

Drawing out features which will achieve those goals using feature injection

Involving stakeholders in the implementation process through outsidein software development

Using examples to describe the behavior of the application, or of units of code

Automating those examples to provide quick feedback andregression testing

Using 'should' when describing the behavior of software to help clarify responsibility and allow

the software's functionality to be questioned

Using 'ensure' when describing responsibilities of software to differentiate outcomes in the

scope of the code in question from side-effects of other elements of code.

Using mocks to stand-in for collaborating modules of code which have not yet been written

http://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-2http://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Domain-driven_designhttp://en.wikipedia.org/wiki/Domain-driven_designhttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-rbehave-3http://en.wikipedia.org/wiki/RSpechttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-rbehave-integ-4http://en.wikipedia.org/wiki/Cucumber_(software)http://en.wikipedia.org/wiki/Cucumber_(software)http://en.wikipedia.org/w/index.php?title=Aslak_Helles%C3%B8y&action=edit&redlink=1http://en.wikipedia.org/wiki/Software_lifecyclehttp://en.wikipedia.org/wiki/Behavior-driven_development#BDD_practiceshttp://en.wikipedia.org/wiki/Behavior-driven_development#Outside.E2.80.93inhttp://en.wikipedia.org/wiki/Behavior-driven_development#Application_examples_in_the_Gherkin_languagehttp://en.wikipedia.org/wiki/Behavior-driven_development#Scenario_1:_Refunded_items_should_be_returned_to_stockhttp://en.wikipedia.org/wiki/Behavior-driven_development#Scenario_2:_Replaced_items_should_be_returned_to_stockhttp://en.wikipedia.org/wiki/Behavior-driven_development#Programmer-domain_examples_and_behaviorhttp://en.wikipedia.org/wiki/Behavior-driven_development#Using_mockshttp://en.wikipedia.org/wiki/Behavior-driven_development#Referenceshttp://en.wikipedia.org/wiki/Behavior-driven_development#External_linkshttp://en.wikipedia.org/wiki/Specification_by_examplehttp://en.wikipedia.org/wiki/Specification_by_examplehttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Scope_(programming)http://en.wikipedia.org/wiki/Mock_objecthttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-2http://en.wikipedia.org/wiki/Test-driven_developmenthttp://en.wikipedia.org/wiki/Test_casehttp://en.wikipedia.org/wiki/Domain-driven_designhttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-origin-0http://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-rbehave-3http://en.wikipedia.org/wiki/RSpechttp://en.wikipedia.org/wiki/Behavior-driven_development#cite_note-rbehave-integ-4http://en.wikipedia.org/wiki/Cucumber_(software)http://en.wikipedia.org/w/index.php?title=Aslak_Helles%C3%B8y&action=edit&redlink=1http://en.wikipedia.org/wiki/Software_lifecyclehttp://en.wikipedia.org/wiki/Behavior-driven_development#BDD_practiceshttp://en.wikipedia.org/wiki/Behavior-driven_development#Outside.E2.80.93inhttp://en.wikipedia.org/wiki/Behavior-driven_development#Application_examples_in_the_Gherkin_languagehttp://en.wikipedia.org/wiki/Behavior-driven_development#Scenario_1:_Refunded_items_should_be_returned_to_stockhttp://en.wikipedia.org/wiki/Behavior-driven_development#Scenario_2:_Replaced_items_should_be_returned_to_stockhttp://en.wikipedia.org/wiki/Behavior-driven_development#Programmer-domain_examples_and_behaviorhttp://en.wikipedia.org/wiki/Behavior-driven_development#Using_mockshttp://en.wikipedia.org/wiki/Behavior-driven_development#Referenceshttp://en.wikipedia.org/wiki/Behavior-driven_development#External_linkshttp://en.wikipedia.org/wiki/Specification_by_examplehttp://en.wikipedia.org/wiki/Regression_testinghttp://en.wikipedia.org/wiki/Scope_(programming)http://en.wikipedia.org/wiki/Mock_object

7/31/2019 Mc0069 Paper 2

20/20

10. Explain with a neat diagram how you would model the architecture of a system.