Q1.

) A) Draw a use case diagram for Online Human Resource (HR, system)
System <<include>> Login

Feed Employee Data

H.R Clerk

<<include>> Feed Daily attendence <<include>>

<<include>> View Attendence & Salary Details

Employee

FeedBack of Subordinates

Add/Delete/Modify Employee Data

Generate Monthly Salary Slips

H.R Manager

Maintain Recruitment Details

Feed Employee Data Description: Information about candidates who become employee in the company is recorded by the H.R Clerk.

Invoking Actor: H.R Clerk Assumptions: --Pre-Conditions: --Post-Conditions: --Scenarios: New Candidate is recruited in the Company & information about him is stored. Benefiting Actor: --Participating Actor: H.R Clerk

Feed Daily Attendence Description: Everyday attendance record is stored in the database. So as to generate monthly salary slips. Invoking Actor: H.R Clerk. Assumptions: ------Pre-Conditions: Employee detail must be there stored in the system Post-Conditions: ---Scenarios: Perday attendance of employees has to be stored in the system. Benefiting Actor: --Participating Actor: H.R Clerk

View Attendence & Salary Details Description: Each employee can view his/her attendance and salary status details. Invoking Actor: Employee. Assumptions: --Pre-Conditions: Employee must have a login Id to View his/her details. Post-Conditions: --Scenarios: Employee wants to view his/her Attendence and salary details. Benefiting Actor: Participating Actor: Employee.

Login Description: Used to authenticate H.R clerk, H.R manager & Employee. Invoking Actor: H.R clerk, H.R manager & Employee. Assumptions: -Pre-Conditions: -Post-Conditions: -Scenarios: -Benefiting Actor: Participating Actor: H.R clerk, H.R manager & Employee.

Feedback of Subordinates Description: Employees who have subordinates under them will give their feedback about each of its subordinates. Invoking Actor: Employee. Assumptions: It is assumed that in the organization Higher level employess gives their feedback about the employees working under them for their performance evaluation. Pre-Conditions: -Post-Conditions: --Scenarios: --Benefiting Actor: Participating Actor: Employee.

Add/Delete/Modify Employee Data Description: H.R Manager can Add, Delete, Modify Employees Record in case of they leaving the Job or being Promoted. Invoking Actor: H.R Manager. Assumptions: --Pre-Conditions: --Post-Conditions: --Scenarios: --Benefiting Actor: --Participating Actor: H.R manager

Generate Monthly Salary Slip Description: Monthly Salary Slips are generated to be sent to the Accounting Department and Employees Invoking Actor: H.R Manager Assumptions: -Pre-Conditions: -Post-Conditions: --Scenarios: -Benefiting Actor: Employee and Accounting Department. Participating Actor: H.R Manager.

Maintain Recruitment Details Description: Each and Every Recruitment done by the H.R Department is recorded in the System. Invoking Actor: H.R Manager. Assumptions: -Pre-Conditions: -Post-Conditions: -Scenarios: -Benefiting Actor: -Participating Actor: H.R Manager.

B) Define the following term? 1) UML

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other nonsoftware systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process.

 The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software. UMl is an extensive language that allow you to construct several views of a system through the use of its different diagram Functional View The Functional View provides the functional specification of the methods that are to operate within designate containers in the Interface View. The Functional View describes the system using UML notions and notations such as Class Diagrams and State Machine Diagrams. The Functional View allows the designer to model the object-oriented structure of the system and its sequential behaviour only. Static structural view This view define the static structure of the system. Class and object diagrams fulfill this view.A class diagram defines the legal configuration of the system. Behavioural (dynamic structural)view This view define the temporal behavior of the system.UML interaction diagram (in particular , collaboration and sequence diagram) depict the specific sequence of interaction between object in different scenarios. Architectural view This view outline the logical and physical structure of the systems major building block. Component diagram show the programming language source and binary unit architecture . Goal of UML The primary goals in the design of the UML were: 1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide a formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts such as collaborations, frameworks, patterns and components. 7. Integrate best practices.

2) Actors An actor in the Unified Modeling Language (UML) "specifies a role played by a user or any other system that interacts with the subject."

"An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject." "Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., role) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances." UML 2 does not permit associations between Actors. Yet, this constraint is often violated in practice since the generalization/specialization relationship between actors is useful in modeling overlapping behaviors between actors.

3) Use case To model system function , UML offers the use case. Jacobson adopted this term because a use case describe how an actor uses the system . Therefore , a use case represent a function that would make sense on an actor. Use cases can be identified in any of several ways. Jacobson recommends that you consider how each actor interacts with the system. That is , ask yourself two questions: i) What interaction with the system does the actor initiate? ii) Whtat interaction with the actor does the system initiate? Each such interaction is a use case. In the business functional model for DryGood.com , a catlog customer partici[ates in at least five functions and initiate all five: i) ii) iii) iv) v) The placing of an order. The cancelling of an order. The cancelling of an order item. The returning of an order item. Various queries about orders.

4)Swimlanes

A swimlane is a way to group activities performed by the same actor on an activity diagram or to group activities in a single thread. Figure 2 includes three swimlanes, one for each actor.
Figure1 . A UML activity diagram for the enterprise architectural modeling (simplified).

Q.2: A) Differentiate between

1. specialization and aggregation (page 128-UML-charles Richter) Specialization versus aggregation: The use of class specialization can result in an inflexible design. In some cases, employing aggregation instead produces a superior solution. One such example is the specialization of a class along different (unrelated) dimensions: Another example is a property shared by some, but not all, subclasses. In some cases, multiple inheritance is used in situations that call for aggregation. These problems and their solutions are described. Aggregation: The advantages of hiding an aggregate's parts within the aggregate are outlined. Different approaches that allow an aggregate's parts to be reused in other applications are examined.

2. Ternary and Reflexive associations (page 61-UML-charles Richter) Ternary and Reflexive Associations : The degree of all of the associations described until now is two, meaning that each relates two classes. UML permits the specification of associations of any degree, however. The notation for associations of degree three or greater is a diamond with "legs" to all classes that participate in the association, as depicted in Figure 2.22.

Passenger

Seat

name address Flight flightNumber date

rowNumber seatNumber

While ternary (and larger) associations are permitted in UML, you should normally try to avoid them during design. One reason is based on human cognition: Such associations are not intuitive and are somewhat difficult to describe. In a ternary association, for instance, there are six cardinality constraints. What is the best means to specify those constraints? Another problem with ternary associations is that they have no standard implementation idioms. Binary associations have idioms, such as the containers (lists) described above, but how would you implement the association in Figure 2.22? If the association is implemented as a class (where each instance of the class is a link), why not simply introduce that class in the design? In Figure 2.23, for example, the ternary association in Figure 2.22 has been transformed into the Seat Assignment class. An instance of this class represents a ternary link between a Passenger, Seat, and Flight instance. UML also allows reflexive(or recursive) associations in which a class is linked to another.An Example such association is shown below:

Employee

0..1 manages

name age

3. method overriding and polymorphism (page 78-UML-charles Richter)

Method Overriding and Polymorphism : Consider the example in Figure 2.43. A run method has been introduced in the Automobile class. Note also that a run method is defined in Vehicle, the super class of Automobile. The Automobile class is overriding the run implementation it inherits from Vehicle, which means that it is replacing the inherited run behav-ior with its own variant. The run implementation in Automobile may either call the run implementation inherited from Vehicle (in which case it extends, rather than replaces, the behavior), or it may ignore the inherited implementation altogether.

Vehicle

vehicleID nun()

Automobile race( ) run()

FIGURE 2 .43 Overriding a method.

Consider the Java code fragment for method x .-f (repeated from Section 2.5.2, "Type Promotion"): class X { public static void f(Vehicle v) { V. run() ; } }

Suppose that you call x.f,passing a reference to an Automobile. Which run implementation will be invoked? The compile-time type of the reference in x.f is Vehicle, which means that if the decision is made at compilation (or link) time, the run method in Vehicle will be called. On the other hand, the execution-time class of the object to which v refers in this example is Automobile; therefore, if the binding is deferred until execution time, Automobile's run method could be invoked. In the typical case, the binding is delayed until execution time; so, the run method for Automobile will be called. (There are ways to force binding at com-pilation time, but that is beyond the scope of this book.) This means that, even though an Automobile object is being referenced as a vehicle, it still acts like what it really is anAutomobile. This is referred to as run-time (or execution-time) binding, polymorphism, or single dispatching. (The "dispatching" part of the last term refers to the selection of a method implementation, whereas the "sin-gle" portion indicates that the selection is based on the type of a single object. In the example, the correct implementation of run is selected based on the type of the object on which run is invoked.)

Note: Polymorphism means many forms; therefore, the mere overriding of a method technically would qualify as polymorphism, regardless of when the binding occurs. The customary use of the term, however, includes execution-time binding. What are the advantages of type promotion and polymorphism? Consider this scenario of a system that has text and binary files. You occasionally must print files, but text and binary files employ different print implementations. If you were to write C-style code to print files, you would do something like the following: class Client { public void handleFile (File f) { switch (f.getType()) { case TEXT: // print text file case BINARY: // Print binary file } } } In other words, each time you must print a file, you introduce conditional code that is based on the type of the file . You originally intended to write this condi-tional code only once, but over time, the code is duplicated in several places. When confronted with your colleagues' comments about the proliferation of conditional code, you offer that there shouldn't be any additional types of files. After all, other than text and binary files, what types of files could possibly exist? Over time, of course, you encounter several new file types, each printed in a different way. PostscriptTM files, for example, require the invocation of a Postscript driver. Image files require some rendering of the image. In each case, You must find every occurrence of the conditional printing code and add a new condition with the code to print the new type of file. The alternative to the preceding conditional code is to employ type promotion and polymorphism. A File superclass defines the print method. Each different type of file is represented by a subclass of File that implements the print method appropriately for that type of file. An initial hierarchy with Text File and Binary File is depicted in Figure 2.44.

File

name print()

Text File print()

Binary File

print()

FIGURE 2.44 The initial File class hierarchy. A client that prints files is passed a reference to a specific type of file, but the client receives it as a reference to a generic File. The client code for printing files is as follows: class Client { public void dolt (File f) { f.print(); // polymorphic print call } } Note that this client code is completely ignorant of the specific (sub)types of files. In some part of your application, of course, you must create the specific types of files. You should strive to restrict the code that is aware of the File subclasses to a small part of your application. After creating instances of specific type of File subclasses, promote those references to be of type File(and deal only with files in the rest of the application). Adding a new type of file requires adding a new subclass. Figure 2.45 illus-trates the addition of an Image File. The preceding client code does not change, because it deals only with generic File references.

File

name print()

Text File print()

Binary File

Image File

print()

print()

FIGURE 2 . 4 5 Introducing an Image File class. Following is a list of the benefits of type promotion and polymorphism: They allow clients to be unaware of specific subclasses. The client is given a reference to the more abstract superclass type (avoiding a form of cou-pling called subclass coupling or subtype coupling). They shield the client from changes in the subclasses. Adding or removing subclasses does not affect the client. Changing existing subclasses does not affect the client (as long as the interface of the superclass does not change). In some languages, they can lessen the need for recompilation. As long as the public interface of the superclass is unchanged, the client need not be recompiled. This is a major issue in large systems (Lakos 1996, 327-471). A client should therefore refer to the most general type possible.

Q.2.B)Explain the extension mechanism used in UML notation.(page87-UML-charles Richter)

Different programming languages offer different sets of features. For example, Java has the Class metaclass, and Smalltalk implements the full metaclass pro-tocol, but many other languages have no explicit metaclasses. Java also has interfaces, whereas Smalltalk and C++ have no analogous construct; C++ has an explicit friend relationship not present in other languages. How is it possible for a notational system to accommodate all of these variations? Furthermore, you may want to model concepts that don't lend themselves to graphical depiction. One example is a constraint, which is simply a rule that the implementation cannot violate. How could you hope to formulate a graphi-cal language that permits all the various forms of constraints?

To address these needs, UML includes a set of mechanisms that allow the addi-tion of new things to the UML notation. The mechanisms come in two general forms: Annotation mechanisms: These are annotations of existing items in a UML diagram. The two annotation mechanisms are specifications and adorn-ments. Extension mechanisms: These allow the introduction of new properties, constraints, stereotypes, etc.

Q 3 b.) Write a short notes on: i) Class Generalization

As you define classes, you may notice that some classes have the same attributes or the same operations. When this is the case, you place these common features (attributes, operations, and so on) in a more generic class called the superclass. The classes that share the common features are known as subclasses of the superclass. This process of finding similar attributes or operations across classes is known as generalization.

The process for showing a generalization in UML is simple: 1. Identify the subclasses. Locate classes that have the same attributes and/or operations. These classes are your subclasses. 2. Create a superclass. Provide a superclass to hold the common attributes and/or operations of the subclasses. Give the superclass a name that categorizes all the subclasses. Placing the superclass above the subclasses in the diagram make it easier to read but is not required.) 3. Add common features to the superclass. Remove the common attributes and operations from the subclasses and place them (once) in the superclass. 4. Draw a generalization relationship. You draw a generalization line from each subclass to the superclass. In UML the generalization line is represented as a solid line with a hollow arrowhead at the superclass end. In UML, a line with the hollow arrowhead that connects a subclass to a superclass is known as a generalization relationship. Figure 1 shows the beginnings of several generalizations, arranged in an inheritance hierarchy.

Figure 1: Simple inheritance hierarchy. ii)class specialization In contrast to generalization, specialization means creating new subclasses from an existing class. If it turns out that certain attributes, associations, or methods only apply to some of the objects of the class, a subclass can be created. The most inclusive class in a generalization/specialization is called the superclass and is generally located at the top of the diagram. The more specific classes are called subclasses and are generally placed below the superclass.

In followingFigure, the class Freight (1) has the attribute Degree of Hazardousness (2), which is needed only for cargo, but not for passenger luggage. Additionally (not visible in Figure 4.28), only passenger luggage has a connection to a coupon. Obviously, here two similar but different domain concepts are combined into one class. Through specialization the two special cases of freights are formed: Piece of Cargo (3) and Piece of Luggage (4). The attribute Degree of Hazardousness (5) is placed where it belongsin Piece of Cargo. The attributes of the class Freight (1) also apply to the two subclasses Piece of Cargo (3) and Piece of Luggage (4):

Figure 4.28 Example of specializatio

So much for the mechanism. However, the domain meaning of the relationship between superclass and subclass is much more important. These rules apply to this relationship:

All statements that are made about a superclass also apply to all subclasses. We say that subclasses inherit attributes, associations, and operations from the superclass. For example: If the superclass Freight has an attribute Weight, then the subclass piece of luggage also has an attribute Weight, even though this attribute is not listed in the subclass Piece of Luggage. Anything that can be done with an object of the superclass can also be done with an object of the subclass. For example: If freight can be loaded, pieces of luggage can also be loaded.

In the terminology of the system that is being modeled, a subclass has to be a special form of the superclass. For example: A piece of luggage is a special case of freight. The counter-example to this is: A flight is not a special case of a flight number. iii)Coupling

Cohesion is a measure of the diversity of an entitys feature .the less diverse its feature are the more cohesive the entity is. In other word,a highly cohesive entity represent a single concept . Because many simpler elements are generally preferable to cated ones, each entity in a design should be as cohesive as possible. Coupling, on the other hand, occurswhen one element of design depends on another in some way. Therefore the-greater the interdependence among element the higher the leve,1 of coupling. When possible, coupling should be avoided. a changr in one element may necessitate a corresponding change in other elements that depends on that element. As its coupling is reduced, a design-generally becomes more maintainable and extensible.

Q 5) A)Draw an activity diagram to model flow for goods returning system.

Login

Select Order

Select Order Items

Choose Transport Mode

Enter Train Number, Date of dispatch & challan No

Enter Transport Name, Dod & Challan No

Generate Refund Bill

Refund Confirmation

B) Explain bottom-up approach of a system in detail.

A bottom-up approach is the piecing together of systems to give rise to grander systems, thus making the original systems sub-systems of the emergent system. In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed.

This strategy often resembles a "seed" model, whereby the beginnings are small but eventually grow in complexity and completeness. However, "organic strategies" may result in a tangle of elements and subsystems, developed in isolation and subject to local optimization as opposed to meeting a global purpose. In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a "seed" model, whereby the beginnings are small, but eventually grow in complexity and completeness. Object-oriented programming (OOP) is a programming paradigm that uses "objects" to design applications and computer programs. In Mechanical Engineering with software programs such as Pro/ENGINEER, Solidworks, and Autodesk Inventor users can design products as pieces not part of the whole and later add those pieces together to form assemblies like building LEGO. Engineers call this piece part design. This bottom-up approach has one weakness. Good intuition is necessary to decide the functionality that is to be provided by the module. If a system is to be built from existing system, this approach is more suitable as it starts from some existing modules. Pro/ENGINEER (as well as other commercial Computer Aided Design (CAD) programs) does however hold the possibility to do Top-Down design by the use of so-called skeletons. They are generic structures that hold information on the overall layout of the product. Parts can inherit interfaces and parameters from this generic structure. Like parts, skeletons can be put into a hierarchy. Thus, it is possible to build the overall layout of a product before the parts are designed.

Q.7
A)Explain Object Synchronization One, source of concurrency in the stock-trading system is the presence of multiple Entry Clients simultaneously accessing the same order Server or Account Server, This opens the possibility that two Entry Clients (that is, two Service Representatives) might attempt to simultaneously access .the same

Order or Account instance. ,Suppose, for example, that one Service Representative is transferring money into an Account while another is removing money from that same account without any locking ,the two modification could conflict . In general the level of locking can be any of the following A class or method is se uential. When invoked on an instance, a sequential me thod neither checks nor grabs the lock of that instance. This may mean that the method can execute concurrently with any other method called on the instance.. A sequential class is one in all methods are sequential. class or method is concurrent (or synchronous in earlier versions of UML.).A concurrent method grabs a lock on the instance on which it. was invoked. Then, it holds that lock throughout the duration of the execution of the method. Just before control is returned to the caller, the lock is released. This blocks out requests. from all other clients, while the method is in progress. 'A class is guarded. The class provides methods that a client must invoke on an in instance of the class to Jock and subsequently unlock that instance. When a class is guarded the client must invoke lock (or seize) to obtain the lock on an inc,tance before calling any other methods on the instance. If the instance already locked by another client when the client invokes lock the client - thread or process must wait until the lock becomes available. The synchronization semantics of a class or method is depicted as a _property of -that entity. The Stock class in Figure 8.22 includes a property indicating its instance are guarded. The class lists the lock and unlock methods used to lock and unlock a Stock instance.In the account class in the figure., the fudbuy and fundSell methods are concurrent, indicating that an Account instance locks itself when one of those methods is invoked. The balance method on the other hand, seqqcntial. It does no locking, and so it can be invoked on_ aninstaiace while that instance is simultaneously handling another request. (Because the' balance method simply returns the balance of the Account, the assumption is that no locking is required.)

Stock(guarded)

newBuyorder() newsellorder() lock() unlock()

Account

Fundbuy() Fundsell() Balance()

The client code isn't cluttered with calls to the locking and unlocking methods (for example,_lock and unlock). Clients simply invoke the application-specific methods provided by the service object. You don't have to depend on clients to behave correctly. With a guarded Stock dass,3."../ient must lock a Stock instance before using it. What if the client forgets to 'unlock an instance the client has locked? What if a client unlocks an instance that is. currently locked by another client? Circular waiting (that is, deadlock) may be easier to prevent. This situa-tion can result when you have a cycle of locking dependencies. For example,suppose Client 1 has locked A and is trying to lock B, while, Clint 2 has locked B and wants to lock A. Clients 1 and 2 will wait forever on e7Nothe7. With guarded 13Ting, a client can hold a lock for a long - period of time. to prevent deadlock, therefore, you must predict clients' patterns of grabbing and holding locks. With concurrent locking, on the other hand, a lock is held only during the execution of a method. Deadlocks, therefore, are due to circular calling patterns, and these are typically easier to find than deadlocks in guarded schemes. Concurrent _policies can be ,changed without the client's knowledge (and, therefore, without altering the client). Suppose you discover that an Account can safely handle a fundBuy and a fundSell request simultaneously. In an Account class with concurrent locking, that modification is internal to the class. In a guarded Account, however, the lock method must be extended to include an argument that indicates how the client intends to use the Account, and the client code must altered to supply the appropriate value.

b)Explain reuse of framework with respect to: i)white box framework ii)black box framework ans

A component represent an attempt to achieve large scale . for the most part, however , a component is a monolithic entity. Customization is typically achieved by adding external behavior and by composing component together. A framework on the other hand is a set of classes that work together to achieve a purpose but that must be specialize by the designer.

A frame work defines a family of related application in a general way. It contains the element that are common to those application.

Black box framework:

Black-box frameworks consist of concrete and ready-to-use classes and services. Although developers can extend the existing framework components to achieve customization in a black-box framework, they more often adapt the framework by combining a number of components to create the desired result. A black-box framework may contain many common spots, and it employs the composition approach to enable its hot spots. Figure 2-8 illustrates a black-box framework.

Figure 2-8. A black-box framework Because of the composition approach in a black-box framework, it provides a greater range of flexibility than that of a white-box framework. Developers can pick and choose different components to achieve specific application requirements with infinite possibilities. Unlike white-box frameworks, where a developer often needs to know the detailed implementation of the framework component for adaptation, black-box frameworks consist of components that hide their internal implementation. Adaptation of such components is done through well-defined interfaces, such as certain public methods and properties. Developers need to be familiar with only these public members in order to use the framework. Compared with white-box frameworks, black-box frameworks are harder to develop. Encapsulating business-domain expertise into components that are generic enough to be used in many application scenarios is not an easy task. Encapsulating too much will lead the domain expertise inside the component becoming less fit in many application scenarios. Encapsulating too little will lead to developers having to work with a large number of components and more complex coordination logic in order to build the application. Although developers dont have to deal with learning the internal implementation of the abstract class as they do with a white-box framework, they do have to be familiar with a

greater number of components and their use when using a black-box framework, since the developer now has more moving parts to deal with in order to combine them into something they need. When developing an application framework, there is no requirement that the framework contain either all abstract classes or all concrete classes. In fact, neither pure white-box nor black-box frameworks are practical in the real world. Having a mix of both the inheritance approach and composition approach gives you the freedom to use whatever approach is best for the design of a particular component. By mixing white-box frameworks and blackbox frameworks, you effectively create a gray-box framework.

White box framework

White box frameworks take both inheritance and composition approach, is usually made up with combination of abstract classes and concrete classes. The approach of enabling its common spots and hot spots is determined on a component-by-component basis. Figure 2-9 shows a white-box framework.

Figure 2-9. A white -box framework

A white-box framework requires the framework user to understand the internals of the framework to use it effectively. In a white box framework, you usually extend behavior by creating subclasses, taking advantage of inheritance. A white box framework often comes with source code. The most common sign that a framework is white-box is heavy use of inheritance. When you use the framework by extending a number of abstract (or even concrete) classes, you are dealing with a whitebox framework. Inheritance is a closer coupling than composition; an inherited class has more context it must be aware of and maintain. This is visible even in Javas protection scheme: a subclass has access to the public and protected parts of the class, while a separate object only sees the public parts. Furthermore, a subclass can potentially break a superclass even in methods it doesnt override, for example by changing a protected field in an unexpected way.