1.Draw and explain the systems architecutre for unified modeling language(5M)

Architecture

The need for viewing complex systems from different perspectives is discussed in Chapter 1.

Visualizing, specifying, constructing, and documenting a software-intensive system demands that

the system be viewed from a number of perspectives. Different stakeholders• end users,

analysts, developers, system integrators, testers, technical writers, and project managers• each

bring different agendas to a project, and each looks at that system in different ways at different

times over the project's life. A system's architecture is perhaps the most important artifact that

can be used to manage these different viewpoints and so control the iterative and incremental

development of a system throughout its life cycle.

Architecture is the set of significant decisions about

• The organization of a software system

• The selection of the structural elements and their interfaces by which the system is

composed

• Their behavior, as specified in the collaborations among those elements

• The composition of these structural and behavioral elements into progressively larger

subsystems•

The architectural style that guides this organization: the static and dynamic elements and

their interfaces, their collaborations, and their composition

Software architecture is not only concerned with structure and behavior, but also with usage,

functionality, performance, resilience, reuse, comprehensibility, economic and technology

constraints and trade-offs, and aesthetic concerns.

Modeling the architecture of a system is discussed in Chapter 31.

As Figure 2-20 illustrates, the architecture of a software-intensive system can best be described

by five interlocking views. Each view is a projection into the organization and structure of the

system, focused on a particular aspect of that system.

Figure 2-20 Modeling a System's Architecture

The use case view of a system encompasses the use cases that describe the behavior of the

system as seen by its end users, analysts, and testers. This view doesn't really specify the

organization of a software system. Rather, it exists to specify the forces that shape the system's

architecture. With the UML, the static aspects of this view are captured in use case diagrams; the

dynamic aspects of this view are captured in interaction diagrams, statechart diagrams, and

activity diagrams.

The design view of a system encompasses the classes, interfaces, and collaborations that form

the vocabulary of the problem and its solution. This view primarily supports the functional

requirements of the system, meaning the services that the system should provide to its end

users. With the UML, the static aspects of this view are captured in class diagrams and object

diagrams; the dynamic aspects of this view are captured in interaction diagrams, statechart

diagrams, and activity diagrams.

The process view of a system encompasses the threads and processes that form the system's

concurrency and synchronization mechanisms. This view primarily addresses the performance,

scalability, and throughput of the system. With the UML, the static and dynamic aspects of this

view are captured in the same kinds of diagrams as for the design view, but with a focus on the

active classes that represent these threads and processes.

The implementation view of a system encompasses the components and files that are used to

assemble and release the physical system. This view primarily addresses the configuration

management of the system's releases, made up of somewhat independent components and files

that can be assembled in various ways to produce a running system. With the UML, the static

aspects of this view are captured in component diagrams; the dynamic aspects of this view are

captured in interaction diagrams, statechart diagrams, and activity diagrams.The deployment view of a system encompasses the nodes that form the system's hardware

topology on which the system executes. This view primarily addresses the distribution, delivery,

and installation of the parts that make up the physical system. With the UML, the static aspects of

this view are captured in deployment diagrams; the dynamic aspects of this view are captured in

interaction diagrams, statechart diagrams, and activity diagrams.

Each of these five views can stand alone so that different stakeholders can focus on the issues of

the system's architecture that most concern them. These five views also interact with one

another• nodes in the deployment view hold components in the implementation view that, in turn,

represent the physical realization of classes, interfaces, collaborations, and active classes from

the design and process views. The UML permits you to express every one of these five views and

their interactions.

2.Explain in detail about the software develpement life cycle(5M)

Software Development Life Cycle

The Rational Unified Process is summarized in Appendix C; a more complete treatment of this

process is discussed in The Unified Software Development Process.

The UML is largely process-independent, meaning that it is not tied to any particular software

development life cycle. However, to get the most benefit from the UML, you should consider a

process that is

• Use case driven

• Architecture-centric

• Iterative and incremental

Use case driven means that use cases are used as a primary artifact for establishing the desired

behavior of the system, for verifying and validating the system's architecture, for testing, and for

communicating among the stakeholders of the project.

Architecture-centric means that a system's architecture is used as a primary artifact for

conceptualizing, constructing, managing, and evolving the system under development.

An iterative process is one that involves managing a stream of executable releases. An is one

that involves the continuous integration of the system's architecture to produce these releases,

with each new release embodying incremental improvements over the other. Together, an

iterative and incremental process is risk-driven, meaning that each new release is focused on

attacking and reducing the most significant risks to the success of the project.

This use case driven, architecture-centric, and iterative/incremental process can be broken into

phases. A phase is the span of time between two major milestones of the process, when a well-

defined set of objectives are met, artifacts are completed, and decisions are made whether to

move into the next phase. As Figure 2-21 shows, there are four phases in the software

development life cycle: inception, elaboration, construction, and transition. In the diagram,

workflows are plotted against these phases, showing their varying degrees of focus over time.

Figure 2-21 Software Development Life Cycle

Inception is the first phase of the process, when the seed idea for the development is brought up

to the point of being• at least internally• sufficiently well-founded to warrant entering into the

elaboration phase.

Elaboration is the second phase of the process, when the product vision and its architecture are

defined. In this phase, the system's requirements are articulated, prioritized, and baselined. A

system's requirements may range from general vision statements to precise evaluation criteria,

each specifying particular functional or nonfunctional behavior and each providing a basis for

testing.

Construction is the third phase of the process, when the software is brought from an executable

architectural baseline to being ready to be transitioned to the user community. Here also, the

system's requirements and especially its evaluation criteria are constantly reexamined against the

business needs of the project, and resources are allocated as appropriate to actively attack risks

to the project.

Transition is the fourth phase of the process, when the software is turned into the hands of the

user community. Rarely does the software development process end here, for even during this

phase, the system is continuously improved, bugs are eradicated, and features that didn't make

an earlier release are added.

One element that distinguishes this process and that cuts across all four phases is an iteration.

An iteration is a distinct set of activities, with a baselined plan and evaluation criteria that result in

a release, either internal or external. This means that the software development life cycle can be

characterized as involving a continuous stream of executable releases of the system's

architecture. It is this emphasis on architecture as an important art if

3.Explain how to Model the Vocabulary of a System.(5M)

Modeling the Vocabulary of a System

You'll use classes most commonly to model abstractions that are drawn from the problem you are

trying to solve or from the technology you are using to implement a solution to that problem. Each

of these abstractions is a part of the vocabulary of your system, meaning that, together, they

represent the things that are important to users and to implementers.

Use cases are discussed in Chapter 16.

For users, most abstractions are not that hard to identify because, typically, they are drawn from

the things that users already use to describe their system. Techniques such as CRC cards and

use case-based analysis are excellent ways to help users find these abstractions. For

implementers, these abstractions are typically just the things in the technology that are parts of

the solution.

To model the vocabulary of a system,

• Identify those things that users or implementers use to describe the problem or solution.

Use CRC cards and use case-based analysis to help find these abstractions.

• For each abstraction, identify a set of responsibilities. Make sure that each class is crisply

defined and that there is a good balance of responsibilities among all your classes.

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

for each class.

Figure 4-9 shows a set of classes drawn from a retail system, including Customer, Order, and

Product. This figure includes a few other related abstractions drawn from the vocabulary of the

problem, such as Shipment (used to track orders), Invoice (used to bill orders), and

Warehouse (where products are located prior to shipment). There is also one solution-related

abstraction, Transaction, which applies to orders and shipments.

Figure 4-9 Modeling the Vocabulary of a System

Packages are discussed in Chapter 12.

As your models get larger, many of the classes you find will tend to cluster together in groups that

are conceptually and semantically related. In the UML, you can use packages to model these

clusters of classes.

Modeling behavior is discussed in Sections 4 and 5.

Most of your models will rarely be completely static. Instead, most abstractions in your system's

vocabulary will interact with one another in dynamic ways. In the UML, there are a number of

ways to model this dynamic behavior.

4.Briefly discuss about Terms and Concepts Relationships.(5M)

Terms and Concepts Relationships

11-13 minutes

Terms and Concepts

A relationship is a connection among things. In object-oriented modeling, the three most important relationships are dependencies, generalizations, and associations. Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the kinds of relationships.

Dependencies

A dependency is a relationship that states that one thing (for example, class Window) uses the information and services of another thing (for example, class Event), but not necessarily the reverse. Graphically, a dependency is rendered as a dashed directed line, directed to the thing being depended on. Choose dependencies when you want to show one thing using another.
Most often, you will use dependencies between classes to show that one class uses operations from another class or it uses variables or arguments typed by the other class; see Figure 5-2. This is very much a using relationshipif the used class changes, the operation of the other class may be affected as well, because the used class may now present a different interface or behavior. In the UML you can also create dependencies among many other things, especially notes and packages.

Figure 5-2. Dependencies

Note
A dependency can have a name, although names are rarely needed unless you have a model with many dependencies and you need to refer to or distinguish among dependencies. More commonly, you'll use stereotypes to distinguish different flavors of dependencies.

Different kinds of dependencies are discussed in Chapter 10; stereotypes are discussed in Chapter 6.

Generalizations

A generalization is a relationship between a general kind of thing (called the superclass or parent) and a more specific kind of thing (called the subclass or child). Generalization is sometimes called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind-of a more general thing (for example, the class Window). An objects of the child class may be used for a variable or parameter typed by the parent, but not the reverse. In other words, generalization means that the child is substitutable for a declaration of the parent. A child inherits the properties of its parents, especially their attributes and operations. Oftenbut not alwaysthe child has attributes and operations in addition to those found in its parents. An implementation of an operation in a child overrides an implementation of the same operation of the parent; this is known as polymorphism. To be the same, two operations must have the same signature (same name and parameters). Graphically, generalization is rendered as a solid directed line with a large unfilled triangular arrowhead, pointing to the parent, as shown in Figure 5-3. Use generalizations when you want to show parent/child relationships.

Figure 5-3. Generalization

A class may have zero, one, or more parents. A class that has no parents and one or more children is called a root class or a base class. A class that has no children is called a leaf class. A class that has exactly one parent is said to use single inheritance; a class with more than one parent is said to use multiple inheritance.
Most often, you will use generalizations among classes and interfaces to show inheritance relationships. In the UML, you can also create generalizations among other kinds of classifiers, such as nodes.

Note
A generalization with a name indicates a decomposition of the subclasses of a superclass on a particular aspect, called a generalization set. Multiple generalization sets are orthogonal; the superclass is intended to be specialized using multiple inheritance to select one subclass from each generalization set. This is an advanced topic that we do not cover in this book.

Associations

An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Given an association connecting two classes, you can relate objects of one class to objects of the other class. It's quite legal to have both ends of an association circle back to the same class. This means that, given an object of the class, you can link to other objects of the same class. An association that connects exactly two classes is called a binary association. Although it's not as common, you can have associations that connect more than two classes; these are called n-ary associations. Graphically, an association is rendered as a solid line connecting the same or different classes. Use associations when you want to show structural relationships.
Associations and dependencies (but not generalization relationships) may be reflective, as discussed in Chapter 10.
Beyond this basic form, there are four adornments that apply to associations.

Name

An association can have a name, and you use that name to describe the nature of the relationship. So that there is no ambiguity about its meaning, you can give a direction to the name by providing a direction triangle that points in the direction you intend to read the name, as shown in Figure 5-4.

Figure 5-4. Association Names

Don't confuse name direction with association navigation, as discussed in Chapter 10.

Note
Although an association may have a name, you typically don't need to include one if you explicitly provide end names for the association. If you have more than one association connecting the same classes, it is necessary to use either association names or association end names to distinguish them. If an association has more than one end on the same class, it is necessary to use association end names to distinguish the ends. If there is only one association between a pair of classes, some modelers omit the names, but it is better to provide them to make the purpose of the association clear.

Role

When a class participates in an association, it has a specific role that it plays in that relationship; a role is just the face the class at the far end of the association presents to the class at the near end of the association. You can explicitly name the role a class plays in an association. The role played by an end of an association is called an end name (in UML1, it was called a role name). In Figure 5-5, the class Person playing the role of employee is associated with the class Company playing the role of employer.

Figure 5-5. Association End Names (Role Names)

Roles are related to the semantics of interfaces, as discussed in Chapter 11.

Note
The same class can play the same or different roles in other associations.

Note
An attribute may be regarded as a one-way association owned by a class. The attribute name corresponds to the end name on the association end away from the class.

Multiplicity

An association represents a structural relationship among objects. In many modeling situations, it's important for you to state how many objects may be connected across an instance of an association. This "how many" is called the multiplicity of an association's role. It represents a range of integers specifying the possible size of the set of related objects. It is written as an expression with a minimum and maximum value, which may be the same; two dots are used to separate the minimum and maximum values. When you state a multiplicity at the far end of an association, you are specifying that, for each object of the class at the near end, how many objects at the near end may exist. The number of objects must be in the given range. You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can give an integer range (such as 2..5). You can even state an exact number (for example, 3, which is equivalent to 3..3).
An instance of an association is called a link, as discussed in Chapter 16.
For example, in Figure 5-6, each company object has as employee one or more person objects (multiplicity 1..*); each person object has as employer zero or more company objects (multiplicity *, which is equivalent to 0..*).

Figure 5-6. Multiplicity

Aggregation

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

Figure 5-7. Aggregation

Aggregation has a number of important variations, as discussed in Chapter 10.

Note
The meaning of this simple form of aggregation is entirely conceptual. The open diamond distinguishes the "whole" from the "part," no more, no less. This means that simple aggregation does not change the meaning of navigation across the association between the whole and its parts, nor does it link the lifetimes of the whole and its parts. See the section on composition in Chapter 10 for a tighter form of aggregation.

Other Features

Plain, unadorned dependencies, generalizations, and associations with names, multiplicities, and roles are the most common features you'll need when creating abstractions. In fact, for most of the models you build, the basic form of these three relationships will be all you need to convey the most important semantics of your relationships. Sometimes, however, you'll need to visualize or specify other features, such as composite aggregation, navigation, discriminants, association classes, and special kinds of dependencies and generalizations. These and many other features can be expressed in the UML, but they are treated as advanced concepts.
Advanced relationship concepts are discussed in Chapter 10.
Dependencies, generalizations, and associations are all static things defined at the level of classes. In the UML, these relationships are usually visualized in class diagrams.
When you start modeling at the object level, and especially when you start working with dynamic collaborations of these objects, you'll encounter links, which are instances of associations representing connections among objects across which messages may be sent.

Drawing Styles

Relationships are shown in diagrams by lines from one icon to another. The lines have various adornments, such as arrowheads or diamonds, to distinguish different kinds of relationships. Typically, modelers choose one of two styles for drawing lines:

Oblique lines at any angle. Use one line segment unless multiple segments are needed to avoid other icons.
Rectilinear lines drawn parallel to the sides of the page. Unless a lines connects two icons that align, the line must be drawn as a series of line segments connected by right angles.This is the style mostly used in this book.

With care, most line crossings can be avoided. If a line crossing is necessary and there is ambiguity about how the paths are connected, a small arc can be used to indicate a line crossing.

Figure 5-8. Line Crossing Symbol

5.Explain how to model a structural relationship with neat diagram.(5M)

Modeling Structural Relationships

When you model with dependencies or generalization relationships, you may be modeling classes that represent different levels of importance or different levels of abstraction. Given a dependency between two classes, one class depends on another but the other class has no knowledge of the one. Given a generalization relationship between two classes, the child inherits from its parent but the parent has no specific knowledge of its children. In short, dependency and generalization relationships are asymmetric.
When you model with association relationships, you are modeling classes that are peers of one another. Given an association between two classes, both rely on the other in some way, and you can often navigate in either direction. Whereas dependency is a using relationship and generalization is an is-a-kind-of relationship, an association specifies a structural path across which objects of the classes interact.
Associations are, by default, bidirectional; you can limit their direction, as discussed in Chapter 10.
To model structural relationships,

For each pair of classes, if you need to navigate from objects of one to objects of another, specify an association between the two. This is a data-driven view of associations.
For each pair of classes, if objects of one class need to interact with objects of the other class other than as local variables in a procedure or parameters to an operation, specify an association between the two. This is more of a behavior-driven view of associations.
For each of these associations, specify a multiplicity (especially when the multiplicity is not *, which is the default), as well as role names (especially if they help to explain the model).
If one of the classes in an association is structurally or organizationally a whole compared with the classes at the other end that look like parts, mark this as an aggregation by adorning the association at the end near the whole with a diamond.

How do you know when objects of a given class must interact with objects of another class? The answer is that CRC cards and use case analysis help tremendously by forcing you to consider structural and behavioral scenarios. Where you find that two or more classes interact using data relationships, specify an association.
Figure 5-11 shows a set of classes drawn from an information system for a school. Starting at the bottom left of this diagram, you will find the classes named Student, Course, and Instructor. There's an association between Student and Course, specifying that students attend courses. Furthermore, every student may attend any number of courses and every course may have any number of students. Similarly, you'll find an association between Course and Instructor, specifying that instructors teach courses. For every course there is at least one instructor and every instructor may teach zero or more courses. Each course belongs to exactly one department.

Figure 5-11. Structural Relationships

The relationships between School and the classes Student and Department are a bit different. Here you'll see aggregation relationships. A school has zero or more students, each student may be a registered member of one or more schools, a school has one or more departments, and each department belongs to exactly one school. You could leave off the aggregation adornments and use plain associations, but by specifying that School is a whole and that Student and Department are some of its parts, you make clear which one is organizationally superior to the other. Thus, schools are somewhat defined by the students and departments they have. Similarly, students and departments don't really stand alone outside the school to which they belong. Rather, they get some of their identity from their school.
The aggregation relationship between School and Department is composite aggregation, as discussed in Chapter 10. Composition is a tight form of aggregation implying ownership.
You'll also see that there are two associations between Department and Instructor. One of these associations specifies that every instructor is assigned to one or more departments and that each department has one or more instructors. This is modeled as an aggregation because organizationally, departments are at a higher level in the school's structure than are instructors. The other association specifies that for every department, there is exactly one instructor who is the department chair. The way this model is specified, an instructor can be the chair of no more than one department, and some instructors are not chairs of any department.
Note
Your school might not have departments. You might have chairs who are not instructors, or you might even have students who are also instructors. That doesn't mean that the model here is wrong, it's just different. You cannot model in isolation, and every model like this depends on how you intend to use these models.

6.List out all basic building blocks and define them with their symbols.(5M)

UML - Building Blocks

As UML describes the real-time systems, it is very important to make a conceptual model and then proceed gradually. The conceptual model of UML can be mastered by learning the following three major elements −

UML building blocks
Rules to connect the building blocks
Common mechanisms of UML

This chapter describes all the UML building blocks. The building blocks of UML can be defined as −

Things
Relationships
Diagrams

Things

Things are the most important building blocks of UML. Things can be −

Structural
Behavioral
Grouping
Annotational

Structural Things

Structural things define the static part of the model. They represent the physical and conceptual elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.
class

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.
Node

Behavioral Things

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things −
Interaction − Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change

Grouping Things

Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available −
Package − Package is the only one grouping thing available for gathering structural and behavioral things.
Package

Annotational Things

Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note - It is the only one Annotational thing available. A note is used to render comments, constraints, etc. of an UML element.
Note

Relationship

Relationship is another most important building block of UML. It shows how the elements are associated with each other and this association describes the functionality of an application.
There are four kinds of relationships available.

Dependency

Dependency is a relationship between two things in which change in one element also affects the other.

Association

Association is basically a set of links that connects the elements of a UML model. It also describes how many objects are taking part in that relationship.

Generalization

Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes the inheritance relationship in the world of objects.

Realization

Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces.

UML Diagrams

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it complete.
UML includes the following nine diagrams, the details of which are described in the subsequent chapters.

Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Activity diagram
Statechart diagram
Deployment diagram
Component diagram