UML DIfferences,Short notes

www.missionmca.com OOMD Differences, Short Notes on Imp topics & Some IMP Ques with Ans Difference between Inheritance and Association Inheritance Association 1. It is identifying and defining a system of hierarchies between classes.

i.

Associations are relationships between attributes & also between classes.

2. Inheritance can be:Generalization Specialization

ii.

An association could be : One-To-One One-To-Many Many-To-One

iii.

There is no concept of super & subclass.

iv.

Associations include cardinality constraints on its end.

3. There is concept of super class and sub class. 4. Inheritance does not include any constraints.

Difference between node and component Node

Component Components represent software.

1. node corresponds to hardware. 2. he node can represent a piece of a larger hardware component, represented by encapsulating the node (having one node inside the other node).

Each component is representative of one or more classes that implement one function within the system.

3. node represents a physical component of the system.

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

Difference between object diagrams and class diagrams Class Diagram :  A class diagram is a static representation of your system. It shows the types of classes, and how these classes are linked to each other  A class diagram is a graph of Classifier elements connected by their various static relationships

www.missionmca.com 

Class diagrams show the logical, static structure of a system and are central the Unified Modelling Language.

Object Diagram :    

A pictorial representation of the relationships between these instantiated classes at any point of time (called objects) is called an "Object diagram." Class diagrams can contain objects, so a class diagram with objects and no classes is an “object diagram.” An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. Object diagrams play a smaller role in UML. They are used primarily for documenting test cases and scenarios.

Difference between object diagrams and class diagrams? A class diagram is a graph of Classifier elements connected by their various static relationships. Note that a “class” diagram may also contain interfaces, packages, relationships, and even instances, such as objects and links. Perhaps a better name would be “static structural diagram”, but “class diagram” is shorter and well established. An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The use of object diagrams is fairly limited, mainly to show examples of data structures. Tools need not support a separate format for object diagrams. Class diagrams can contain objects, so a class diagram with objects and no classes is an “object diagram.” The phrase is useful, however, to characterize a particular usage achievable in various ways. The basic idea is that class diagrams focus on classes and object diagrams focus on objects, but it is possible to mix classes and objects on the same diagram for various purposes, so the separation is not rigid. Class diagrams show the logical, static structure of a system and are central the Unified Modeling Language. Object diagrams play a smaller role in UML. They are used primarily for documenting test cases and scenarios, and for discussing examples.

Difference Between Aggregation and Specialization Aggregation :  Aggregation is to create new functionality by taking other classes and combining them into a new class  An aggregation is the "a part of" relationship in which objects represents the components in same assembly. Aggregation may be the special form of Association.  With aggregation, you get to choose either implementation or interface, or both -- but you're not forced into either. The functionality of an object is left up to the object itself  Example (aggregation) : A Paragraph consists of many sentences. Here Paragraph contains sentences. Specialization :  Specialization is relationship between the classes.  Specialization is the is-a-kind-of relationship, in which the specialization is the subclass, or subtype.  Example:

www.missionmca.com If we have class Vehicle, Automobile and Truck. Then Automobile and Truck is-a-kind-of Vehicle. Vehicle is a super class and Automobile and Truck are subclasses.

Difference between Composition and Aggregation. Aggregation - Without whole part can exist. Composition - Without whole part can't exit. Aggregation One class is a kind of another class. Composition - One class has another class Aggregation - In Design, If you remove "whole" part can exist (BUT In Code No diff.). Composition - In Design, If you remove "whole" part can also be removed automatically (in RSA) (BUT In code no diff). 1. Composition implies real ownership of its components whereas aggregation does not necessarily own any of its aggregates. 2.Composition has a stronger bond of its components whereas aggregation has weaker or looser bonds with its aggregates. 3.Composition has components that exist at the inner level whereas aggregation has aggregates that live at the outer level. Composition : - Two objects are same life time is called composition. Aggregation :- Two objects are different life time is called aggergation. Aggregation uses instances of objects created outside of this class. Composition uses instances of objects that are created as part of this object. Aggregation heavily implies that the aggregate object already exists, to be grouped in the calling object. Composition heavily implies that the composite object should be created by the calling object.

Difference between Event & State Events:  State machines communicate by sending events to one another.  Events are typically treated as operations.  In some cases, an event may corrospond to a signal, such as a hardware interrupt. In other situation, it may correspond to a message, such as a method invocation or an inter-process message.  The term event refers to the type of occurrence rather than to any concrete instance of that occurrence. For example, Keystroke is an event for the keyboard, but each press of a key is not an event but a concrete instance of the Keystroke event.  An event can have associated parameters, allowing the event instance to convey not only the occurrence of some interesting incident but also quantitative information regarding that occurrence. For example, the Keystroke event generated by pressing a key on a computer keyboard has associated parameters that convey the character scan code as well as the status of the Shift, Ctrl, and Alt keys.

www.missionmca.com State :  A state is an abstraction of an object’s state. It can represent particular values for a subset of the object’s attributes a links.  A transition between states, therefore, represents some changes in those values.  A state captures the relevant aspects of the system's history very efficiently. For example, when you strike a key on a keyboard, the character code generated will be either an uppercase or a lowercase character, depending on whether the Caps Lock is active.  A state is depicted in UML as a capsule with name and/or a set of actions.

Difference between Event & State Event

State

1. n event is something that happens at a point in time such as user depresses the left button of mouse.

The attribute values and links held by an object are called its states.

2. n event does not have any duration.

A state is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some event.

Difference between macro process and micro process Micro Processes A. The micro-processes of objectoriented development are largely driven by the stream of scenarios and architectural products. B. It represents the daily activities of the individual developer or a small team of developer. C. It applies equally to the software engineering and software architecture. D. The traditional phases of analysis and design are intentionally blurred, and the process is under opportunistic control.

Macro Processes A. The macro process serves as the controlling framework for the micro process. B. It represents the activities of the entire development team on the scale of weeks to months at a time. C. Many elements of the macro process are simply sound software management practice, and so apply equally to object-oriented as well as non-object-oriented systems. D. The traditional phases of analysis and design are to a large extent retained, and the process is reasonably well defined.

www.missionmca.com White box Framework Vs Black box framework White box Framework  consists of a set of classes that define abstractions.  you define subclasses inherit that abstraction.  inheritance of application.  you must understand the implementation details of the classes in the framework.  subclasses add state and behaviour specific to application.  some framework classes are abstract, many are concrete and some can be used as it is. Black box framework  consists of a set of classes that operate on specific interfaces.  each interface defines a role.  you introduce classes that play those roles by implementing the interfaces.  interface inheritance and polymorphism as principle specialization mechanism.  you are “plugging in” classes to a set of interfaces.  Black-box frameworks are easier to use than white-box.  You must understand only interfaces.

Functional Modelling V/S Object modelling 1. It describes data flow & constraints to describe business process. 2. Weaker approach, then object modeling.

a) It describes the structure of the objects in the system in terms of identity relationship, attribute and operation. b) Strongest approach then functional modeling.

3. It uses DFD for describing business processes.

c) It uses class diagram to describe the system.

4. It is difficult to prototype.

d) It is easy to prototype.

5. It cannot map the model to real world scenario.

e) It maps model to real worlds scenario.

Functional Modelling and object modelling Ans: Functional Modelling 1. Functional modelling provides functional view of the system 2. It is depicted by using the DFD 3. In functional modelling aspects of the system concerned with transformation of values

Object Modelling 1. Object modelling gives static view of the system 2. Class diagrams are used to depict the object modelling 3. Object model describes structure of object in a system & their identity & relationships

www.missionmca.com 4. Functional model captures what a system does without regard for how or when it is done 5. Example: DFD for photocopier software

4. Object model captures those concepts from real world that are important to applications 5. Example: Class diagram for hotel management software

ii)Inheritance and association 1.

2. 3. 4.

Association An association is a relationship between classes in the class diagram. A software designer uses an association to define the dependencies between classes in the implementation. Association describes relationship between the instances Association includes cardinality constraints on its ends Diagrammatic notation: Binary associations (with two ends) are normally represented as a line, with each end connected to a class box. Higher order associations can be drawn with more than two ends. In such cases, the ends are connected to a central diamond.

1.

2. 3. 4.

Inheritance Inheritance is the operation result of specialization, which is the is-a-kind-of relationship, in which a child or (sub class) inherits all attribute, associations, and operations of its parents (super class) Inheritance is solely a relationship between the classes & not between instances No cardinality constraints are shown in inheritance Diagrammatic notation: To show inheritance(specialization), one can draw a separate arrow from each subclass to the super class or use the shared target arrow.

www.missionmca.com 5. UML permits the specification of association of any degree. i.e. ternary or reflexive. This is depicted as:

6.

Some (but not all) languages permits multiple inheritance in which a subclass inherits from more than one immediate super classes, this is depicted as:

Comparison between Sequence and Collaboration diagram Sequence Diagram

Collaboration Diagram

It shows the occurrence of events in a system with respect to time.

It shows organization or relationship of objects.

Objects have a lifeline within sequence diagrams.

It consists of path between objects and sequence number.

It is shown using rectangle with all messages involved in the interaction within the rectangle

It is shown by * and stack of objects involved in the interaction.

Condition is shown in [ ]. Branching is shown Condition is shown in [ ] and the branches using bifurcation and if receives a return from a given object bears the same sequence message, the lifeline is spitted number. Delete statement touches the object.

Delete statement touches the lifeline with an ‘X’.

Timing constraint is included.

Timing constraint is not included.

Activation diagrams present.

Activation diagrams not present.

In Sequence diagrams we can show Synchronous as well as Asynchronous messages.

In Collaboration Diagram we can only shoy Synchronous messages.

Sequence Diagram shows overall flow of System event/s in a given use case.

Collaboration diagram shows how objects interacts with each other how intercommunication b/w objects for a give use

www.missionmca.com case. It’s difficult to fine the responsibilities of objects in sequence diagram.

Its ease to detect the responsibilities of objects in collaboration diagram by just counting the number of arrows coming into the object.

Sequence Diagrams are less spatial.

Collaboration Diagram are much spatial.

Difference between collaboration and sequence diagram in UML 1) Sequence diagram gives you time based interaction between the objects. Collaboration diagram tell how the objects are associated. 2) Sequence diagrams emphasize the time ordering of messages, whereas collaboration diagrams depict more of an organizational structure and are more space efficient. 3) Collaboration diagrams also provide Action between to object (interaction object). Sequence steps achieve functionalities. 4) Sequence diagrams provide the users and life time of the each object. Action between to object. Sequence steps achieve functionalities. 5) Sequence diagram is basically a flow chart w.r.t time. However, a collaboration diagram is very much the sequence diagram without any time. 6) In Sequence diagrams we can show Synchronous as well as Asynchronous messages. In Collaboration Diagram we can only show Synchronous messages. 7) Sequence Diagram shows overall flow of System event/s in a given use case. Collaboration diagram shows how objects interacts with each other how intercommunication b/w objects for a give use case 8) Its difficult to fine the responsibilities of objects in sequence diagram. It’s easy to detect the responsibilities of objects in collaboration diagram by just counting the number of arrows coming into the object. 9) Sequence Diagrams are less spatial. Collaboration Diagram is much spatial. 10) Collaboration Diagram emphasizes the relationships between objects while Sequence diagram emphasizes the time sequence of behaviour. 11) A sequence diagram is effectively a two-dimensional graph with time on one axis and objects of interest on the other. A collaboration diagram is a visualization of a collection of objects linked by interactions, arranged in an attempt to optimize understands ability.

www.missionmca.com Extends

Include/Uses

Extension use case references the base use case.

Base use case refers the inclusion use case.

Extension may be invoked independently.

Inclusion may be invoked independently.

The base use case must be well formed even if extension use case is not invoked.

Base use case may depend on the effects of inclusion use case.

Extension usually takes care of alternate scenario (which might happen to be exception)

Includes relationship may be linked to aggregation of classes.

1. The uses arrow is drawn from a use case A to another use case B to indicate the process of doing A always involves doing B at least once. 2. A uses relation from use case A to use case B indicates that an instance of the use case A will also be include in the behaviour as specified by use-case B.

1) The extends arrow is drawn if a use case A to a use case B, indicate that the process A is a special case behaviour of the same as the more general process B. 2) An Extends relationship from a use case A to use case B indicate that an instance of use case may include the behaviour.

3. The notation is a close-headed arrow annotated with the stereo type name uses.

3) The notation is the enclosed headed arrow directed arrow from the extension with the stereotype annotation.

4. Symbol: 4) Symbol:

5. Example: 5) Example:

www.missionmca.com Architecture pattern versus Design pattern 1. Architectural pattern: It is a problem independent way of organizing a system or subsystem. It describes a structure by which different parts of system are organized or interact. 1. Design pattern: A design pattern is a solution to small problem i.e. independent of any problem domain. It represents a solution to a design problem that to occur in any kind of application. Some design pattern can be applied to different areas like order processing, online shopping cart, banking application or any other system. 2. Architecture pattern: Architectural means how data is flowing in your application. 2. Design pattern: Design pattern means how you are approaching to problem. 3. Architectural pattern: Architectural pattern concentrate on ‘what’. 3. Design pattern: Design pattern concentrate on ‘how’. 4. Architectural pattern: Architecture means flow of particular business logic or project. 4. Design pattern: Design means approach for that particular business logic or project. 5. Architecture pattern: Architectural states how that particular logic to be implemented. 5. Design pattern: Design pattern states the rules and regulation to be followed while implementing some software. 6. Architecture pattern: Architecture is concern with the selection of architectural elements, their interaction and the constraints on those elements and their interaction. 6. Design pattern: Design is concern with the modularization and detects interfaces of design element, their procedure and data type needed to support the architecture and to satisfy the requirements.

What are the advantages of object oriented approach? A) Higher levels of abstraction b) Seamless transition among different phases of software development c) Encouragement of good programming techniques D) Promotion of reusability What is Association class.? An association class is an association that also as class properties. The name in the class symbol and the name string attached to the association path are the same. If an association class has attributes but no operations or other associations, then the name may be displayed on the association path and omitted from the association class to emphasize its “association nature". If it has operations and attributes then the name may be omitted from the path and placed in the class rectangle to emphasize its "class nature".

www.missionmca.com What is an Association rule? An association may have an association name. This name may have an optional black triangle in it, the point of the triangle indication the direction in which to read the name. The end of an association where it connects to a class is called the association role. What do you mean by difference between patterns and frameworks. Ans: A pattern is instructive information that captures the essential structure and insight of a successfully family of proven solutions to a recurring problem that arises within certain context and system of forces. Pattern solves a problem, is a proven concept, describes relationships, and has significant human component. A framework is a way of presenting a generic solution to a problem that can be applied to all levels in a development. It represents a set of classes that make up a reusable design for a specific class of software. It partitions the design into abstract classes and also defines relationships between them. They emphasize design reuse over code reuse. What is a Qualifier? A qualifier is an association attribute. For example, a person object may be associated to a Bank object. An attribute of this association is the account#. The account# is the qualifier of this association.

Bank Account# * 0..1 Person A qualifier is shown as a small rectangle attached to the end of an association path, between the final path segment and the symbol of the class to which it connects. The qualifier rectangle is part of the association path, not part of the class. The qualifier rectangle usually is smaller than the attached class rectangle.

What are the diagrams used in Booch methodology? The Booch methodology consists of the following diagrams: Class diagrams. Object diagrams. State transition diagrams. Module diagrams. Process diagrams. Interaction diagrams What are the advantages of Modeling? Good models are essential for communication among project teams. As the complexity of systems increases, so does the importance of good modeling techniques. Some of the advantages are as follows: Models make it easier to express complex ideas. The main reason for modeling is to reduction of complexity. Models enhance and reinforce learning and training. The cost of modeling analysis is much lower than the cost of similar perimentation conducted in real system. Manipulation of the model is much easier.

www.missionmca.com Class card 

   

    



A class represents a collection of similar objects. An object is a person, place, thing, event, or concept that is relevant to the system at hand. For example, in a university system, classes would represent students, tenured professors, and seminars. The name of the class appears across the top of a class card and is typically a singular noun or singular noun phrase, such as Student, Professor, and Seminar. We use singular names because each class represents a generalized version of a singular object. Class cards were originally introduced as a technique for teaching object-oriented concepts, they have also been successfully used as a full-fledged modeling technique A responsibility is anything that a class knows or does. For example, students have names, addresses, and phone numbers. These are the things a student knows. Students also enroll in seminars, drop seminars, and request transcripts. These are the things a student does. The things a class knows and does constitute its responsibilities. A class is able to change the values of the things it knows, but it is unable to change the values of what other classes know Sometimes a class has a responsibility to fulfill, but not have enough information to do it. Class cards offer a quick, flexible technique for discovering object classes, members and relationships in an object-oriented program Detailed software design and code generation is often driven by UML class diagrams. CRC cards, dictionary data, class diagrams and code are complementary and interchangeable representations of the same project information. Layout of the class card:Class Name

Responsibilities

Collaborators

Example of the class card:-

Student Number Name Address Phone Number

 

Class Name Collaborators

Collaboration takes one of two forms: A request for information or a request to do something. For example, the card Student requests an indication from the card Seminar whether a space is available, a request for information. Student then requests to be added to the Seminar, a request to do something.

www.missionmca.com 

Another way to perform this logic, however, would have been to have Student simply request Seminar to enroll himself into itself. Then have Seminar do the work of determining if a seat is available and, if so, then enrolling the student and, if not, then informing the student that he was not enrolled.

ABSTRACT CLASS An abstract class is a class that is declared abstract—it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed. An abstract method is a method that is declared without an implementation An abstract method is one that defines an interface but no implementation.each subclass must provide its own implementation of that method. An abstract class is one for which instances cannot be createdi.e, an object of it cannot be created.Any class with an abstract method must be abstract.it is not necessary to have an abstract method in an abstract class. When an abstract class is subclassed, the subclass usually provides implementations for all of the abstract methods in its parent class. However, if it does not, the subclass must also be declared abstract. Features of an Abstract Class 1. Abstract Class cannot be instantiated. 2. An Abstract Class must be inherited. 3. It may have Concrete Methods. 4. It may have Abstract Methods. 5. An Abstract Method of an Abstract Class must be overridden. 6. An Abstract Class can only contain Abstract Method.

History States A history state is used to remember the previous state of a state machine when it was interrupted. The following diagram illustrates the use of history states. The example is a state machine belonging to a washing machine.

In this state machine, when a washing machine is running, it will progress from "Washing" through "Rinsing" to "Spinning". If there is a power cut, the washing machine will stop running and will go to the "Power Off" state. Then when the power is restored, the Running state is entered at the "History State" symbol meaning that it should resume where it last left-off.

www.missionmca.com Realizations A realization from a source element (called the realization element) to a target element (called the specification element) indicates that the source element supports at least all the operations of the target element without necessarily having to support any attributes or associations of the target element. For example, an undifferentiated class or implementation class may play the role defined by a type and may provide the service defined by an interface, if the class supports the operations defined by the type and interface. A realization allows us to reuse the operations of types and interfaces where a realization element is said to realize its specification elements. A realization is shown as a dashed-line path from the source element to the target element, with a large hollow triangle at the end of the path connected to the target element. When the target element is an interface shown as a small circle, the realization is shown as a solid-line path connecting the source and interface.

Swimlanes Activity diagrams tell you what happens, but they do not tell you who does what. In programming, this means that the diagram does not convey which class is responsible for each activity. In domain modeling, this means that the diagram does not convey which people or departments are responsible for each activity. One way around this is to label each activity with the responsible class or human. This works, but does not offer the same clarity as interaction diagrams for showing communication among objects. Swimlanes are a way around this. To use swimlanes, you must arrange your activity diagrams into vertical zones separated by lines. Each zone represents the responsibilities of a particular class or a particular department. Swimlanes are vertical or horizontal bands in a diagram that divide the diagram into logical areas or partitions. In the example below the activities relating to particular entities within the model (such as the User, or the back end Repository) are placed within a containing swim lane to indicate their association.

www.missionmca.com

‘Extend’ and ‘Include’ in use cases ‘Extend’ and ‘Include’ define relationships between use cases. Below figure ‘Extend and Include’ shows how these two fundamentals are implemented in a project. The below use case represents a system which is used to maintain customer. When a customer is added successfully it should send an email to the admin saying that a new customer is added. Only admin have rights to modify the customer. First lets define extend and include and then see how the same fits in this use case scenario. Include: Include relationship represents an invocation of one use case by the other. If you think from the coding perspective its like one function been called by the other function. Extend: This relationship signifies that the extending use case will work exactly like the base use case only that some new steps will inserted in the extended use case. Below figure ‘Extend and Include’ shows that ‘add customer’ is same as the ‘add discounted customer’. The ‘Add discounted customer’ has an extra process, to define discount for the discounted customer which is not available for the simple customer. One of the requirements of the project was that when we add a customer, the system should send an email. So after the customer is added either through ‘Add simple customer’ use case or ‘Add discounted customer’ use case it should invoke ‘send a email’ use case. So we have defined the same with a simple dotted line with as the relationship.

www.missionmca.com

Figure: Extend and Include Note: One of the points to be noted in the diagram ‘Extend and Include’ is we have defined inheritance relationship between simple and admin user. This also helps us defining a technical road map regarding relationships between simple and admin user.

Representation of private, public and protected in class diagrams In order to represent visibility for properties and methods in class diagram we need to place symbols next to each property and method as shown in figure ‘Private, Public and Protected’. ‘+’ indicates that it’s public properties/methods. ‘-‘indicates private properties which means it can not be accessed outside the class. ‘#’ indicate protected/friend properties. Protected properties can only be seen within the component and not outside the component.

Figure: Private, public and protected

www.missionmca.com Composite structure diagram and reflexive association in class diagrams Composite structure diagram When we try to show Aggregation and Composition in a complete project the diagram becomes very complicated so in order to keep it simple we can use Composite structure diagram. In the below figure we have shown two diagrams one is normal diagram other is Composite structure diagram and the simplicity can easily be identified. In the composite diagram the aggregated classes are self contained in the main class which makes it simpler to read.

Figure: Composite Structure diagram

Reflexive associations In many scenarios you need to show that two instances of the same class are associated with each other and this scenario is termed as Reflexive Association. For instance in the below figure shows Reflexive Association in the real project. Here you can see customer class has multiple address class and addresses can be a Head office, corporate office or Regional office. One of the address objects is Head office and we have linked the address object to show Reflexive Association relationship. This is the way we can read the diagram Regional address object is blocked by zero or one instance of Head office object. Kinds of reflexive association : asymmetric reflexive association (4 facts) - A reflexive association in which the roles at either end are different. symmetric reflexive association (3 facts) - A reflexive association in which the roles at either end are identical

www.missionmca.com

Figure: Reflexive association

Generalization and specialization In Generalization and Specialization we define the parent-child relationship between the classes. In many instance you will see some of the classes have same properties and operation these classes are called super class and later you can inherit from super class and make sub classes which have their own custom properties. In the below figure there are three classes to show Generalization and Specialization relationship. All phone types have phone number as a generalized property but depending upon landline or mobile you can have wired or simcard connectivity as specialized property. In this diagram the clsphone represent Generalization whereas clslandline and clsmobile represents specialization.

Figure: Generalization and Specialization

Package diagrams Packages are like folders in a system which allows you to logically group UML diagrams. They make complex UML diagram readable. In actual projects they are used to logically group use cases and classes. So we can say there are two types of package diagrams one is class package diagram and other is use case package diagram. Package diagram depict a high level of overview for class and use cases. Class package diagram: - Class package diagram are used to logical group classes. You can think that package technically map to ‘Package’ in JAVA and ‘Namespaces’ in C# and VB.NET. Packages are denoted by small

www.missionmca.com rectangle on a big rectangle as shown in figure ‘Package diagram’. One of the points to be noted is the stereotypes. We have numbered the figure so that we can understand it better. 1 – We are using the MVC (Model View controller) framework. So we have denoted this package using the > stereo type. Refer the commonly used stereo type table discussed in the previous sections. 2 and 3 – ‘Book tickets’ is the second package which inherits from the MVC model. The stereo type is ‘’ which means it’s a user interface. 4 – A simple line shows a link between two classes stating that one class package uses the other class package. 5 – This package is collection of the booking engine library. 6 – The final package is the database.

Figure: - Package diagram As said before packages are nothing but collection of logical classes or any UML entity. We have shown the detail of the above package diagram. We should restrict from using package diagram for showing the in depth architecture as it can become very complicated. For instance the below diagram ‘Detail Package diagram’ shows how complicated it can look if use the package diagram to show in depth architecture. To avoid complication its good to only draw an over all diagram as shown in ‘Package diagram’.

Figure: - Detail Package diagram Use case package diagram: - The way we have logically grouped classes we can also use the package diagram to logically group use cases. Below figure shows how a use case package diagram looks like.

Figure: - Use Case Package

www.missionmca.com “SBI” of an object SBI stands for State, Behavior and Identity. Since every object has the above three. State: It is just a value to the attribute of an object at a particular time. Behaviour:It describes the actions and their reactions of that object. Identity: An object has an identity that characterizes its own existence. The identity makes it possible to distinguish any object in an unambiguous way, and independently from its state.

Coupling: 1) Coupling is the measure of interconnection among modules in a software structure like cohesion; coupling may also be represented on a spectrum. 2) Coupling depends on the interface complexity between modules, the point at which entry or reference is made and what data passes across the surface. 3) Then lowest possible coupling is optimum. 4) Simple connectivity amongst modules results in software, that is easier to understand and less prone to a ripple effect caused when error occurs at one location and propagates through the system. 5) Types of coupling: 1. Data coupling: 1) If the modules communicate via an elementary data item, which is passed as parameter between the two then the modules are called as data coupled. 2) This data item should be problem related and not used for the control purpose. 3) Example: passing an integer to a function which computes a square root. 2. Stamp coupling: If modules communicate via a composite data item such as a structure in C, then they are stamp coupled. 3. Control coupling: 1) If data from the module is used to direct the order of execution of instructions in another module, then the modules are control coupled. 2) Example: a flag id set in one module and is tested in another module 4. Common coupling: If two modules share some global data area then they are common coupled. 5. Content coupling: 1) If the modules share their code then they are content coupled. 2) Example: a branch from one module into another module 6) The degree of coupling is in ascending from data coupling to content coupling.

Stereotypes in uml 1) A stereotype defines a constraint that i similar to some other construct, but has special semantics. 2) Any notational construct can be stereotyped. 3) The name of the stereotype appears in guillemets (or double angle brackets if guillemets are unavailable).

www.missionmca.com 4) Actors are normally modelled in a class diagram as stereotyped classes, where the name of the stereotype is . 5) Actor classes are like normal classes in that they have instances, can be associated with other classes, and can have a public interface. 6) They differ from regular classes, however, in that they are not implemented. 7) They are black boxes to one’s design. 8) Any UML construct can be stereotyped. 9) The specialization relationship for the uses and extends relationships between use cases is also stereotyped. 10) Dependencies can be stereotyped for template instantiation. The following example includes a stereotyped dependency (binds) for template instantiation also contains a model fragment with a stereotyped class and stereotyped dependencies. The Order Not Pending Exception class is special, because its instances are exceptions.

0..1

Telephone Agent

orderNumber timePlaced

Order Not Pending

order



cancel() commit() addLineItem() totalPrice()

Guidelines for flexible design     

A flexible design is one that is extensible or reusable. New features can be added to an extensible design relatively painlessly. Ideally, adding a new capability should affect as few classes as possible. A reusable design is one that can be used, either entirely or in part, in another system or application. To increase its flexibility, an object-oriented design should exhibit several properties: 1. High cohesion: 1) Cohesion is a measure of the degree to which an entity does just one kind of thing. 2) The more cohesive it is, the more it limits itself to one area of interest. 3) Classes should be cohesive in that they should represent a single abstraction. 4) A class that is not cohesive is more difficult to understand and, in some cases, to extend. 5) Operations should also be cohesive in that each should handle a single responsibility. 2. Low coupling: 1) Coupling measures what an entity needs to know about the world around it. 2) Coupling involves what a class or object knows about other classes or objects.

www.missionmca.com 3) Low coupling means that the classes and objects know as little as possible about other classes and objects. 4) If one class is coupled to another and the public interface of that second class changes, the implementation of the first class may be affected. 5) Reducing coupling can limit the scope of a change to the design. 3. An even distribution of behaviour: 1) One must strive to keep state and behaviour together in an object and to have that object “do things for itself”. 2) In doing so, one can avoid objects that control other objects. 4. Strong modularity: 1) This is the degree to which “like things” are grouped together. 2) One strives to group objects into meaningful packages, subsystems, processes, and so forth.

Artifacts • An artifact in the Unified Modeling Language (UML) is the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system. • Examples of artifacts include model files, source files, scripts, and binary executable files, a table in a database system, a development deliverable, or a word-processing document, a mail message. • In UML 2.0, artifacts are the physical entities that are deployed on Nodes, Devices, and Execution Environments. Other UML elements such as classes and components are first manifested into artifacts and instances of these artifacts are then deployed. Artifacts can also be composed of other artifacts.

Patterns 1. Patterns are parameterized collaborations; that is, they are a group of collaborating objects/classes that can be abstracted from a general set of modeling scenarios. 2. Patterns are an excellent means of achieving re-use and building in robustness.

3. As patterns are discovered in any new project, the basic pattern template from previous engagements can be re-used with the appropriate variable names modified for the current project. 4. Patterns generally describe how to solve an abstract problem, and it is the task of the pattern user to modify the pattern elements to meet the demands of the current engagement. 5. Before using a pattern it must first be created as a standard UML diagram and then saved as an XML pattern file. This XML file can then be imported as a UML Resource that can be used in any model.

Actor Class  

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

www.missionmca.com 

     

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. UML treats actors as special stereotyped classes. A atereotype class is like a normal class, but it has special semantics. Like normal class, an actor class can have instances; it instances can communicate with objects in the system. Unlike a normal clacc, however, an actor class is a black box because you don’t have to implement it or understand its internal details. The normal notation for a stereotype is to place the name of the stereotype within guillemets. In case of the actor class stereotype, UML provides a special graphical adornment : the stick figure.

Join – Fork 1. The Fork/Join elements have different modes of use, as follows: a) To fork or split the flow into a number of concurrent flows. b) To join the flow of a number of concurrent flows. c) To both join and fork a number of incoming flows to a number of outgoing flows. 2. A fork node is a control node that splits a flow into multiple concurrent flows... A fork node has one incoming edge and multiple outgoing edges. 3. A join node is a control node that synchronizes multiple flows... A join node has multiple incoming edges and one outgoing edge. 4. Fork vertices in the UML Statechart Diagram serve to split an incoming transition into two or more transitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not have guards or triggers. Join vertices serve to merge several transitions emanating from source vertices in different orthogonal regions. The transitions entering a join vertex cannot have guards or triggers. 5. A Fork notation in a UML Activity Diagram is a control node that splits a flow into multiple concurrent flows. This will have one incoming edge and multiple outgoing edges. A join node is a control node that synchronizes multiple flows.This will have multiple incoming edges and one outgoing edge. Q) Compare and contrast the approaches for developing class diagrams. Ans: Class Diagram: class diagrams are the mainstay of object-oriented analysis and design. class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detailed design modeling. eg:

www.missionmca.com

There are approaches to develop class diagram: 1) from Noun Phrase 2)using Abstraction 3)Using Use Cases Developing class diagrams from Noun Phrases: ● One approach of identifying classes is to use syntactic elements of a problem statement. ● The abstraction that represent classes appear as Noun Phrases in the description/Specification of the syntax. ● Examples of such abstractions: i)Physical Objects: credit card scanners, automobiles etc ii)Roles: Customer, patient and doctor. iii)Concepts: Review processes, tax tables. ●

EG: Library Checkout System

Developing class diagrams using Abstraction: ● This method is more efficient but one should be problem domain expert to abstract the system. ● Several methods adopt this technique. Each method provides a set of identification keys to identify major abstractions. ● keys such as: i)find kind-of or part-of relations. List the relationship and the classes involved in them. ii)find what other systems interact in them. iii)find other devices interacting with system. ● Object Oriented System Analysis(Modelling the world in DATA, SHLAER and MELLOR) ● Object Oriented Development : The fushion method. Developing class diagrams using Use Cases: ● The Use case diagram is used to identify the primary elements and processes that form the system. ● The primary elements are termed as "actors" and the processes are called "use cases." ● The Use case diagram shows which actors interact with each use case. ● A use case diagram captures the functional aspects of a system. ● Use case diagrams define the requirements of the system being modeled and hence are used to write test scripts for the modeled system ● EG: Tracking the States of Machines. Comparing the Approaches :

www.missionmca.com Approaches

Advantages

Disadvantages

Noun Phrases

i) The Process is almost i) Very tedious process if mechanical, it is helpful in the problem definition is too situation when you are not large. certain how to start. ii) Little problem domain knowledge required because ii)It requires written problem problem definition itself gives definition but all the idea. organisations are not providing it. iii) There is a very clear stopping rule: as one will look at all noun phrases will identify classes. iii) Quality of the model highly depends on quality of problem definition and many other descriptions are not good enough.

Abstraction

Use-Cases

i) It is very efficient in terms of development time and effort compared to Noun phrases and Use cases.

i) It is difficult to trace design and implementation back to requirements.

ii) It is good use of problem domain expertise.

ii) It requires deep knowledge of problem domain.

i) The model contains features i) For large systems to that are justified by identify Use cases is behaviour. discouraging. ii) Use cases are good vehicles for explaining and validating requirements.

ii) Written Classes for Use cases is not straight forward.

Q) The Booch methodology prescribes a macro development process and a micro development process. 1.The Macro Development Process The macro process serves as a controlling framework for the micro process and can take weeks or even months. The primary concern of the macro process is technical management of the system. Such management is interested less in the actual object-oriented design than in how well the project corresponds to the requirements set for it and whether it is produced on time. The macro development process consists of the following steps:

www.missionmca.com 1. Conceptualization 2. Analysis and development of the model 3. Design or create the system architecture 4. Evolution or implementation 5. Maintenance 2.The Micro Development Process The micro process is a description of the day-to-day activities by a single or small group of software developers. The micro development process consists of the following steps: 1.Identify class and objects 2.Identify class and objects semantics 3.Identify class and object relationships 4.Identify class and object interfaces and implementation.

Q) Relationships Between Classes In a class diagram, obviously you can't have classes just floating around; you need to see the relationship between them. The following table shows the kinds of relationships between classes, their notation, and what they mean. Sr. Relation No. 1

Symbol

Association

Description When two classes are connected to each other in any way, an association relation is established. For example: A "student studies in a college" association can be shown as:

1 a. Multiplicity

An example of this kind of association is many students belonging to the same college. Hence, the relation shows a star sign near the student class (one to many, many to many, and so forth kind of relations).

1 b. Directed Association

Association between classes is bidirectional by default. You can define the flow of the association by using a directed association. The arrowhead identifies the container-contained relationship.

1 c. Reflexive Association

2

Aggregation

No separate symbol. However, the relation will point back at the same class.

An example of this kind of relation is when a class has a variety of responsibilities. For example, an employee of a college can be a professor, a housekeeper, or an administrative assistant. When a class is formed as a collection of other classes, it is called an aggregation relationship between these classes. It is

www.missionmca.com also called a "has a" relationship. 2 a. Composition

Composition is a variation of the aggregation relationship. Composition connotes that a strong life cycle is associated between the classes.

3

Inheritance/Generalization

Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.

4

Realization

In a realization relationship, one entity (normally an interface) defines a set of functionalities as a contract and the other entity (normally a class) "realizes" the contract by implementing the functionality defined in the contract.

Different views of the system that UML allows to constructs: 1. Use-Case View: The use case view of a system encompasses the use cases that describe the behaviour of the system as seen by it’s end users, analysis and testers. 2. Design View: The design view of the system encompasses the classes, interfaces and collaborations that form the vocabulary of the problem and its solution. It supports the functional requirements of the system. 3. Process view: The process view of a system encompasses the processes that form the system’s concurrency and synchronization mechanisms. It addresses the performance, scalability and throughput of the system. 4. Implementation view: The implementation view of a system encompasses the components and files that are used to assemble and release the physical system. It 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.

5. Deployment view: The deployment view of a system encompasses the nodes that joins the system’s hardware topology on which the system executes. It addresses the distribution, delivery and installation of the parts that make up the physical system.

www.missionmca.com Q) Discuss top-down and bottom-up approaches. Ans. Top down Design of System Dynamics – It is originates from use cases. It is top-down because you start with general items, use cases then you walk through scenarios to identify very specific items, object methods and required links between objects. It employs use cases to drive the overall process. It moves from general (use cases) to specific (methods). Top down design of system dynamics can be illustrated with a stock trading example. Steps of Top Down approach are as follows 1. Identify the use cases of system behavior. 2. Specify and refine each use case. 3. Define a scenario for each interesting path through use case. 4. Draw interaction diagram for each scenario. 5. Identify object methods from object interactions in the interaction diagrams. 6. Define each state-based objects behavior with a state transition diagrams using interaction diagrams for guidance. Bottom up Design of System Dynamics – It is starting with specific object responsibilities like methods, attributes, links. Then move to use scenarios to validate and expand those responsibilities. Starting point is objects(links, attributes and methods. It moves from specific to general. This process is the opposite of the top-down approach because it starts with specific object methods and then uses scenario primarily as a validation. Bottom up approach described by library system example. Steps of Bottom up approach are as follows 1. Identify the classes in the system. 2. Make a list of the responsibilities of the objects of each class. 3. Identify interesting scenarios that you will use to validate your enumeration of responsibilities. 4. Draw an interaction diagram for each scenario, validating that you have all necessary responsibilities. Add responsibilities as necessary.

Q) Using examples compare and contrast the various relationships that can exist between classes. In UML, object interconnections (logical or physical), are modeled as relationships. There are three kinds of relationships in UML: • Dependencies • Generalizations • Associations • 1. Dependency Relationships A dependency indicates a semantic relationship between two or more elements. The dependency from CourseSchedule to Course exists because Course is used in both the add and remove operations of CourseSchedule.

www.missionmca.com

2. Generalization Relationships A generalization connects a subclass to its superclass. It denotes an inheritance of attributes and behavior from the superclass to the subclass and indicates a specialization in the subclass of the more general superclass.

UML permits a class to inherit from multiple superclasses, although some programming languages (e.g., Java) do not permit multiple inheritance.

3. Association Relationships If two classes in a model need to communicate with each other, there must be link between them. An association denotes that link.

We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association. The example indicates that a Student has one or more Instructors:

The example indicates that every Instructor has one or more Students:

www.missionmca.com We can also indicate the behavior of an object in an association (i.e., the role of an object) using rolenames.

We can also name the association.

We can specify dual associations.

A class can have a self association.

We can model objects that contain other objects by way of special associations called aggregations and compositions. Aggregation An aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part, where the part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornment on the association.

Composition A composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live and die as a whole). Compositions are denoted by a filled-diamond adornment on the association.

www.missionmca.com

UML Extension Mechanism UML is a universal software modeling language that provides an abundance of well-defined modeling concepts and notations to meet all the requirements of general software modeling. Nevertheless, the software modeling/development environment today can take many different forms, and there may be requirements for elements or semantics that do not exist in the UML standard. By default, UML provides concepts for supporting such requirements, and they are called the UML Extension Mechanisms. Extensibility Mechanisms help to add new building blocks,create new properties and specify new semantics.[2] Extensibility mechanisms provided by UML are as follow:   

Stereotypes Tagged Values Constraints

The UML provides a textual representation for stereotypes, tagged values, and constraints. UML Extension Mechanisms use Stereotypes, Constraints, Tag Definitions, and Tagged Values to extend the semantics of UML modeling elements or define the UML modeling elements with new semantics. Stereotypes Stereotypes help to introduce new graphical symbols.It is an extension of list of words and their meaning used in UML. Diagrammatically, a stereotype is rendered as a name enclosed by guillemets (French quotation marks of the form « »), placed above the name of another element or by using new icon or both.The stereotyped element may be rendered by using a new icon associated with that stereotype.[2] Node or a class like elements are stereotyped by creating a new building block just like an existing one but with its own special modeling properties, semantics and notation. Stereotypes help to add new things to the UML. Operation Stereotypes Stereotypes used to group together operations with common characteristics are called operation stereotypes. They represent a metaclassification of the operation.[2] Tagged Values A tagged value is a property of a stereotype.It helps to create new information in an element bearing that stereotype.It help to add new properties to a stereotype.Different types of tag can be defined that can be applied to different stereotypes. Diagrammatically, a tagged value is rendered as a string of the form name = value within a note attached to the object.[2] The values of properties of model elements is referred to as tagged values when a stereotype is applied to it. It

www.missionmca.com represent arbitrary information which is expressed in text form.It is commonly used to store Project Management information.

Constraints A constraint is a textual specification of the semantics of a UML element.[2]It help to add new rules or to redefine the existing ones.Constraints may be written as free-form text.A constraint specifies conditions that a run-time configuration must satisfy to conform to the model. Time and space constraints are used for modeling real time systems.It restrict the values that object or links can assume.Constraints may be attached to more than one element by using dependencies.[2] Diagrammatically, a constraint is rendered as a string enclosed by brackets and placed near the associated element or connected to that element or elements by dependency relationships.Also as an alternative,constraint can be rendered in a note. Constraints between two elements are depicted using a dotted, labeled line.

Q) What are the benefits and drawbacks of identifying classes using Abstraction and Noun Phase approach? The benefits of Abstraction are as follows: 1. It is very efficient in terms of development time and effort because you do not underline nouns or describe use cases. 2. It is therefore a good use of problem domain expertise. The drawbacks of Abstraction are as follows: 1. It requires extensive knowledge of the problem domain. Only a domain expert can use this approach effectively. Furthermore, the quality of the model is highly dependent on both the knowledge and skill of the domain expert. 2. It can be difficult to trace design and implementation constructs back to requirements. If use cases are employed, classes can be traced to use cases to written requirements. If noun phrases are isolated from a problem statement, classes can be traced back to noun phrases. With abstraction, however, there is nothing available to which to trace classes. 3. It can result in analysis paralysis: agonizing over details that aren’t in the model. 4. The certainty that everything is being thought of is not there i.e. when to stop is not obvious.

www.missionmca.com The benefits of Noun Phase are as follows: 1. The process is almost mechanical and, hence, is appealing in situations where how to start is uncertain. 2. It requires little, if any, problem domain knowledge, provided a written description of the system is available. 3. There is a very clear stopping rule: when all the noun phrases have been looked upon, the identification of classes finishes. The drawbacks of Noun Phase are as follows: 1. It is a very tedious process, and the written description of a large system could be hundreds of pages long. 2. It requires a written description of the problem to be solved. Many development organizations are never provided such a description. 3. The quality of the model highly depends upon the quality of the problem statement, and many problem descriptions are not very good.

Q) Describe architectural pattern and design patterns. 1. Architectural Patterns: 1) An architectural pattern is a problem-independent way of organizing a system or subsystem. 2) It describes a structure by which the different parts of a system are organized or interact. 3) When organized using the Pipes and Filters pattern, an application consists of a set of filters that communicate with one another using data streams, or pipes. 4) Each filter reads data from one or more input pipes, transforms that data, and then writes its results to one or more output pipes. In most cases, an output pipe of one filter is an input pipe of another. 2. Design Patterns: 1) A design pattern is a solution to a small problem that is independent of any problem domain. 2) It represents an attractive solution to a design problem that could occur in any kind of application. 3) The same design pattern can be applied in areas as diverse as order processing, factory control, and meeting room scheduling. 4) Different design patterns solve different kinds of problems. 5) Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. 6) Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such. 7) Design patterns reside in the domain of modules and interconnections. 8) At a higher level there are architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.

Q )What are the benefits of reuse? What the various forms of reuse in object oriented development. Explain. Ans: Reuse of design and code is often cited as a principle benefit of object-oriented development.Reuse is not a single concept it comes in different sizes and shapes.The scale of the reusable item can be anything from a single class to a large component consisting internally of hundreds of classes Several forms of reuse in object-oriented developments are: • Reuse of classes

www.missionmca.com •

Reuse of components

•

Reuse of frameworks

•

Reuse of patterns

REUSE OF CLASSES: • The simplest and probably most common form of reuse is the reuse of individual classes •

These classes are packed in the form of a class library (package in java)

•

Classes are typically grouped in terms of functional cohesion

•

i.e. all the classes in one functional area are placed in one library

•

Like in data structure class library, it includes classes for linked list,stacks,queues etc..

•

Consider class lirbrary of financial classes

•

One such class is the Account class

•

This class defines the interface & implementation of a basic cash-bearing account

•

This Account maintains a cash balance, it has method to deposit cash itself,withdraw cash from itself & return its current balance.

• •

•

Disadvantage Class based reuse is that the scale of reuse is very small Much of the state & behavior of some class is specific to application, but as you add more fetures, you make the class less reusable in other domains Reuse of Components: Whereas a class is relatively small reusable part, a component is building block, is reused as a single unit

•

An application can include a set of component whose execution-time instances(binaries) collborate by invoking operations in one another

•

A component’s scale is much larger than that of a class.

•

A component may be composed of many classes internally.

•

A component is a non-trival,nearly independent and replaceble part of system that fullfills a clear function in the context of a well-defined architecture.

•

A component conforms to and provides the physical realization of a set of interfaces. Reuse of Framework:

•

Diffrence between component & framework:

www.missionmca.com •

A component represents an attempt to achieve large-scale reuse. For most part, component is a monolithic entity.

•

Whereas framework is a set of classes that work together to achieve a purpose but that must be specialized internally by the designer.

•

A framework defines a family of related application in a general way

•

It contains the element that are common to those application

•

e.g. Handling sales order & service orders are similar activities that act on very similar entities Two types of framework: White-Box framework: It consist a set of classes that define abstraction

• •

Each class defines both the interface & implementation of its abstraction

•

When you specialize a white-box framework,you define subclasses that inherit that abstraction Black-box Framework: It consist of a set of classes that operate on specific interfaces

• •

Each interface defines role

•

Specializing the framework entails introducing classes that play those roles by implementing the interfaces Whereas a white-box framework defines common abstraction as classes, a black-box framework specifies common roles as interfaces classes Reuse of Patterns

•

The classes,components and frameworks are share same property

•

i.e. reusing code

•

The codification & application of patterns reuse the knowledge

•

A pattern is a way of solving a problem

•

A pattern typically promotes a design principle while solving a problem

•

Some patterns strengthen encapsulation

•

i.e. employing a pattern not only provides a solution that you might not have formulated on your own

•

But also makes your design more flexible.

•

Because a pattern embodies the reuse of knowledge rather than code

•

Developing catalogs of patterns has become an important point of emphasis in the object-oriented community

www.missionmca.com There are 2 types of pattern: -Architectural pattern -Design pattern Architectural Pattern:

•

It is a problem-independent way of organizing a system or subsystem It describe a structure by which the different parts of system are organized or interact.

•

Buschmann,Meunier,Rohnert,Sommerlad have been the pioneers in cataloging architectural patterns such as Pipes & Filters.

•

Consider the application consisting the set of filters that communicate with one another using data stream or pipes

•

Each filter reads data from one or more input pipes

•

Transform that data

•

Then writes its result to one or more output pipes.

•

Design Patterns: A design pattern is a solution to a small problem that is independent of any problem domain

•

It represent an attractive solution to a design problem that could occure in any kind of application

•

Same design applied in order processing,factory control & meeting room scheduling

Reuse benefits Increased dependability: Reused software, that has been tried and tested in working systems, should be more dependable than new software. The initial use of the software reveals any design and implementation faults. These are then fixed, thus reducing the number of failures when the software is reused. Reduced process risk: If software exists, there is less uncertainty in the costs of reusing that software than in the costs of development. This is an important factor for project management as it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as sub-systems are reused. Effective use of specialists: Instead of application specialists doing the same work on different projects, these specialists can develop reusable software that encapsulate their knowledge. Standards compliance: Some standards, such as user interface standards, can be implemented as a set of standard reusable components. For example, if menus in a user interfaces are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability as users are less likely to make mistakes when presented with a familiar interface. Accelerated development: Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production because both development and validation time should be reduced.

www.missionmca.com

All the Best!!!