1. More complex software, because of heterogeneous technology (LAN/WAN/Internet), hardware, software and applications.
2. Shorter development cycle because of business commitments
3. Needs higher budget
4. Higher user's expectations
5. Software can only be tested after development is over
6. Poor research at System Analysis and Design phase leads to non-usable system such as USA DMV 43 million$ project
7. Non-scaleable and non-portable systems
8. To cover up the risks such as -
• Attain main objectives from business perspective
• Reach market in time
• Resource risk such as equipment, people and finance
• Fail to manage new technologies
• Architectural risk from implementation angle such as component integration etc.

1. Achieve the objective
2. User should be able to use it effectively
3. Maintainable system
4. Scalable
5. Portable between platforms
6. Reusable code
7. Deliver in time
8. Within budget

1. OOA -
1. model based upon user's requirements
2. from user’s perspective and close to real world
3. processes are “Black Boxes”
4. abstracting from the problem domain
5. OOA is focused on concise, accurate model of WHAT the desired system should do
6. primary classes and objects are discovered such as persistence or inter-process communications
7. Though implementation environment not considered, but it must be ascertained whether the model will work in intended implementation environment
8. Analysis –
1. What to do?
2. Domain?
3. How?
4. What skills?
2. OOD -
1. adds details and decisions to the model i.e. blue print for development
2. from developer’s perspective
3. have “White Box” approach
4. OOD considers HOW the system will perform it’s functions
5. Secondary classes are discovered

1. Single paradigm for analyst, users, developers, implementers and testers to aspect the same system from different perspective.
2. Real World to be more closely modeled
3. Easy to understand and maintain
4. Inheritance gives re-usability of code and architecture
5. Encapsulation gives data security and stability i.e. small changes doesn’t effect the whole system
6. Captures the system and documents it, before the development starts
7. Different solutions can be explored and evaluated before coding starts
8. Different view of the system for different people
9. Can be used as a guideline through out the software development process
10. Abstraction reduces the underlying complexity of the system and allows the system to be viewed as a whole

1. System should be split in to modules based upon logical functionality
2. Modules should be separately compatible, so that if changes need to be made to one of them, the whole system won’t be affected.
3. Modules should interact with each other through compact and minimum interfaces, which acts as wrappers to hide the implementation

1. allow an accurate description of the system
2. be as simple as possible, without being oversimplified
3. be easy to update
4. be easy to communicate with others

UML basic concepts -

1. Common elements comprises of -
1. Model elements represent abstractions of the system
2. Visual elements provide textual or graphical projections that facilitate the manipulation of model elements
2. Common mechanisms are –
1. Stereotypes permits users to add new model element classes on top of the kernel pre-defined by UML.
2. Tagged values (name, value) pair describes the property of a model element.
3. Notes are comments attached to one or more model elements.
4. Constraint is kind of semantic relationship between model elements. Object Constraint Language (OCL) is preferred language for this.
5. Dependencies are unidirectional relationship between source and target model elements.
6. Type/instance dichotomies are element with type essence and type/class dichotomies, corresponds to the split between the specifications of an element.
3. Data type -
1. Boolean enumerates two types True or False.
2. Expression scope goes beyond UML.
3. Multiplicity is a non-null set of positive integers.
4. Name character string that enables the specification of an element.
5. Integer is primitive type and an element of the infinite set of positive, negative and whole numbers.
6. String is primitive type and is sequence of characters referred to by a name.
7. Time is a character string representing absolute or relative duration, whose syntax goes beyond the scope of UML.
8. Uninterrupted thing, which’s meaning depends upon the domain and is undefined in UML.
4. Package - It provides general mechanism for logical partitioning models and grouping model elements. A package may contain mixture of packages and other model elements, the way as a directory may contain other directories and files.

1. To model complete OO and Relational system
2. Coupling of the conceptual and executable articrafts
3. Scalability and support both small and large scale analysis and design
4. Notations for both people and machines

1. Standard
1. UML notation and processes
2. Model - Model tells us the problem and solution to the problem domain in UML notations and is highly self-contained basic unit of development, which is loosely coupled with other models by navigational links. Semantically representation like class, objects and relationships based upon object-oriented concepts.  Each model element retains same symbol and meaning in different diagram such as class diagram.
3. Diagram - Different combination of Model elements based upon rules. Nine diagrams are -
1. Use-case represents the functions of a system from the user's point of view.
2. Class represents the static structure in terms of classes and relationships.
3. Object represents objects and their relationship, and correspond to simplified collaboration diagram that do not represent message broadcasts.
4. State-chart represents the behaviors of a class in terms of states.
5. Sequence Interaction (extra information than Collaboration diagram)
6. Collaboration Interaction (initial discovery phase because it's close to reality)
7. Activity represents the behavior of an operation as a set of actions.
8. Component represents the physical components of an application.
9. Deployment represents the deployment of components on a particular piece of hardware.
4. View - Views are combination of diagrams and provides highest level of abstraction for analyzing the system from various aspects. Taken together, the view of the system provides a picture of the system in it entirety. Five main views are –
1. Use-case
2. Logical
3. Component
4. Concurrency
5. Deployment
2. Non-standard - UML provides mechanisms for adding comments, information, or semantics to diagrams. Customization gives extensibility to UML and it provides mechanisms to adapt or extend itself to a particular method, software system or organization. These are -
1. Comments
2. Information
3. Semantics

Obsolete Waterfall software life-cycle approach -

1. Requirements capture - Most of the user’s requirements are captured via simple use-case, class and activity diagrams for users, clients and developers.
2. Analysis - Existing use-cases are expanded and new use-cases are defined. Classes are discovered to fulfill use-case functionality and class relationships are defined via class diagrams. State, Sequence, Collaboration and Activity Diagram can document behavior and state. Interface Screens, Windows, Events and Screen Navigation are carried out. Then the members involved do evaluation.
3. Design - Considers environment and implementation details. Classes are grouped into functional packages. After this technical classes are developed to implement functional requirements defined in Analysis. These classes should provide mechanism such as persistence, inter-process communication, exception and error handling. Consider available pre-compiled libraries. If table, then map these classes to relational database. Allocate classes to source code component and components to packages via component diagrams. Executable components allocated to processors and devices i.e. nodes and this is done via Deployment diagram. Diagram and specification are translated into syntax of programming language.
4. Implementation - Define programming guidelines and start coding. Code review from simplicity, re-usability and maintainability angle. Compilation, linking and debugging. Do unit testing and integration of components. Old diagrams are updated.
5. Test - Find and eliminate the errors. Test cases tell a tester as what to input and what results to get against Sequences, Collaboration and Deployment diagrams. Automatic and manual testing via test scripts. Test can be at component level done by the programmers. Integration test checks the interfaces and communication mechanisms. Functionality from specific user's can be checked via use-cases. Test from intended user via use-case collected in Capture phase.

1. Each phase is isolated in itself because of linear in approach
2. Loss of information because each step is managed by different people
3. Error are discovered at the end only i.e. Test
4. User interaction is not continuous

1. Use-case driven - Series of logical steps in a system to yield results to user and defines the behavior of the system. User is an actor, which can be a machine or man. Can also be used as to test the system.
1. Use-cases realized in design model.
2. Use-cases are implemented in implementation model.
3. Use-case are verified in test model
2. Architecture driven - We can visualize, alter and extend system before development starts. This divides the system into packages and sub-systems. Good system has well-defined layers of abstractions and each layer has standard interface to interact with each other. It also considers non-functional elements of a system.
3. Incremental and iterative - Iteration refers to problem solving method that uses a series of approximations, each one building on the last, to find a better solution. Each iteration of a system should result in value being added to the model i.e. address problem in previous iteration and add a new functionality. Implementation and testing happens after iteration. This reduces the risk as member involved can evaluate prototype at an early stage.

1. Inception - Original version of the product is transformed into project. Project access, risk assessment, resource estimation, plan and milestones. At times part of implementation phase carried out here i.e. prototyping or showing user interface or both.
2. Elaboration - More analysis i.e. extend and discover new classes and use-cases. Cost and duration should be clearly defined. Rough calculations on size and iteration of the project.
3. Construction - Iteration of analysis, design and programming. New articrafts are produced such as documentation from user and technical angles.
4. Transition - Delivery to the user and system is put to actual use. Develop plan for packaging, pricing, roll out, support, training, transition strategy, production details and improvisations on documentation. After that each iteration keeps on generating beta release, bug-fix and upgrades. Postmortem analysis is done at the end. In UML these are the following seven phases in the software development cycle -

1. Plan 15%
2. Analysis 10%
3. Architect 15%
4. Implemenation 30%
5. Maintaince 5%
6. Test 15%
7. Change Management 10%

1. Allows new requirement to incorporate in the system
2. Early detection of risk elements
3. Easy to detect reusable components
4. Robust Architecture
5. Team is better integrated throughout the software cycle

1. Requirements Managements - Systematic approach to dealing with the changing requirements of a software intensive system
2. Change Control - Deals with changes in requirements, design and implementation
3. Quality Control part is also a part in Objectory, which covers objective measurement, criteria for all activities and participants in the process. Objectory can be described having two components -
1. Time represents dynamic aspects such as cycles, phases, iterations and milestones
2. Process components are the static elements such as process components, activities, workflow, articrafts and workers.

1. Fragmentations in late 80’s -
1. James Rambaugh had Object Management Technology (OMT)
2. Grady Booch had Booch methodology focuses on practice of analyzing a system as a series of macro and micro views
3. Ivar Jacobson had Object Oriented Software Engineering (OOSE) focuses on the analysis of system behavior. Also it advocates that at each step there should be a check to see that the requirements of the user were being met
2. ii) Unification -
1. In 1994 OMT joined Booch and made Unified Method
2. In 1995 OOSE joined Unified Methods.
3. State charts of Erric Gamma and David Harrel were also incorporated and named it UML. It was broken down to notations rather than methods.
3. iii) Standardization and Industrialization -
1. In 1997, Object Management Group (OMG) standardized the UML ver 1.0. UML standardizes -
2. Diagrams
3. Syntactic notations
4. Semantic models

1. Elimination of superfluous elements
2. Important elements are not left out

1. System commissioner
2. System Manager
3. Manager
4. Staff
5. Clients
6. Purchaser

1. Designers and users are in agreement about what the system should do
2. Speed up the design process
3. Both combined i.e. use-case models and problem domain, gives clear picture of the future system, without using any technical jargons and thus more closer to user.
4. Use-case is system functionalities from an actor's point of view. Use-case is diagrammatic (i.e. actors as stick-man, relations as line, use-case oval and system boundary as square) along with textual representation of relation between actors, it’s surrounding functionality (complete from start to finish, where finish means an observable result to an actor) and use-cases. Customer, developer and domain expert are responsible for use-case models. Analysis, design and testing teams use same use-case model. They are flexible and can be changed. Scope of use-case should not be too wide otherwise it may take longer to deliver. Instead focus on creating an accurate system architecture that can be added to easily. Steps for use-cases are about -
1. Defining system
2. Identify Actors
3. Identify use-cases
4. Defining relationship between (including associations, dependencies and generalization) -
1. Actor and use-case
2. Among use-cases
5. Use-case is realized in either collaboration or sequence i.e. transformation into classes and objects.  This means defining classes and objects, and their relationships and operations. Use-case functionality gets assigned to class. Use-case boundaries are determined by the interaction of an actor. This tells developer what system should and should not do, along with the interface. Active actor linked to use-case can initiate use-cases. Also there should be textual description about the use-case functionality. Use-case is represented by an oval and name at the bottom.
6. Actor is an external entity (not a part of the system such as person, another system or printer etc.) to the system and becomes an interface of the system. Actor is a role and not an individual user. One person can play a role of many actors. Actor is a class and not an instance of an object. Actor class can have behavior and attributes as well as documentation property that describe the Actor. Actors have a name depending upon its role and not on functionality. Nor the Actor name should represent an instance of a class. Actor can be primary or secondary. An active Actor (Passive Actor merely participates in one or more use-cases) can initiate a use-case but a passive actor only participates in the use-case. Actor is represented by stickman. Since UML is flexible we can choose an actor depending upon the level of abstraction. Progressions through iterations may generate more Actors. An Actor can –
1. inputting information
2. receiving information
3. inputting and receiving information
7. Explode different alternate flow along with the exceptions the use-cases with sequence or collaboration diagrams. Along the development use-cases gets enhanced. But use-cases don't tell as how to achieve the functionality? Use-case functionalities are implemented in classes and operations. Use-cases should be written in such a manner that even a non-technical person should be able to understand it.
8. Inputs in the use-case development process by -
1. Customer
2. End users
3. Domain Experts
4. Developers
9. Use-case model represented by the use-case view. This view affects all of the other system views such as logical and physical views, because the functional specifications are implemented in these architectures.
10. How to define use-case -
1. Find an actor, by exploring what the system should do?
2. UML is flexible, so choosing actors often depends on the level of abstraction you want in a use-case.
3. Design iterations may add more actors and use-cases.
4. Check out what things interact with the system.
5. Different functionality will have different Actors, because functionality is isolated to an Actor.
6. In case an Actor has a unique behavior, it can be modeled using actor-generalization association with the original actor.
11. Content of use-case -
1. Unique ID is an intelligent meaningful key for easy tracability
2. Name i.e. named against their functionalities along with the verb like RUN PAYROL.
3. Goal statement is one line statement regading the aim of use-case i.e. what a system does from a user's angle and not how
4. Author is usually a team, along with iterative dates
5. Priority and targeted dates for an early completions
6. Risk means any uncertainty which can cause an issue
7. Actor who is inputting and outputing or both
8. Related use-cases
9. Assumptions are made by the use-case team and not limitations or constraints
10. Pre-conditions describes the conditions that should be met before use-case can be performed
11. Post-conditions describes that comditions must be net before the use-case gets finished
12. Outstanding issues are issues which needs to be resolved to complete this use-case
13. Requirement satisfied can be bulleted list of features
14. Scenarios, which is an instance (examples of specific scenario) of a use-case -
1. Main flow
2. Alternative flow (exception, when system can fail to meet it’s objective)
15. How it gets initiated and ends
16. Extension point
17. Dictonary
18. Annexures
12. Relationship -
1. Generalization
1. between Actors
2. between two use-cases
2. Association from
1. an actor to use-case
2. use-case to an actor
13. Use–case pyramid view -
1. Logical
2. Process
3. Development
4. Implimentation

1. Dynamic behavior, i.e. when object exchange messages while executing scenario are shown by interaction diagrams –
1. Collaboration focuses on - how (relations) the objects are linked. It has objects as rectangle and o:Object,  link as a line, mesage an an arrow, and sequence of steps for each link. Collaboration allows to see -
1. The complete set of services an object will have to provide
2. Interface
3. Linking of object
2. Sequence (focuses on sequences i.e. time v/s class object/actor objects).
2. Complexity and syntactical details are added in design phase. Interact diagram messages often correspond directly to the operations on class diagram. So a class operation can have the same names as the messages sent or received by its objects. We can use interaction diagrams to discover operations for a class. Object, which sends the message is called client, and object which is receiving the message is called supplier, because it provides services for client. An object can also sends a message to itself, which is called self-delegation.
3. UML can represent the following message, which gets mapped to operations of the classes -
1. Simple
2. Synchronous
3. Asynchronous

1. These diagrams focus on HOW via Objects. Classes are template for an Object. By encapsulation relationship makes strong internal cohesion, and weak coupling with outside. An object encapsulates a portion of knowledge of the domain in which they evolve. It’s a static structure and has behavior at a given time. Object’s discovery leads to classes. It uses divided rectangle as an object and it’s attribute and links as lines. Object is an instance of a class. Object is an atomic entity in a system, which has -
1. Identity - an unambiguous name
2. State - dynamic Attributes (instance member variables) are hidden data elements i.e. data is encapsulated by Methods. State evolves with time. Attribute is an essential static part of an object and it represents state of an object. Attributes can be found from –
1. Rejected candidate classes noun analysis
2. Flow of events
3. Problem statement
2. Behavior - also called methods/operations and are responsible for action and re-action of an object. Different operations allow Objects to behave and interact with each other objects. An object is interlinked with other objects via links. If object A is sending message to B, then A knows what B is capable off receiving message. Operations are divided into two parts -
1. Signature is made up of operation’s name, parameters and it’s type. It tells what (black-box view of class) an operation does.  Interfaces are visible (also called published) operations along with attribute definition, which usually allow communication with hidden attributes. Standard interface makes more portable objects such as D-COM/CORBA. Since an Actor is an outside entity, it doesn’t use the operations directly.
2. Implementation is made of actual algorithm and code. It tells how an operation will work.
3. Encapsulation -
1. This pays path for information hiding or encapsulation, which provides security to attributes i.e. data elements of an object. Degree of encapsulation depends upon visibility of its operations and attributes. Three levels of encapsulations -
1. (-) Private - has strong encapsulation, which means that this cannot be used by the client class.
2. (#) Protected - means that it’s can be used by class and sub-classes.
3. (+) Public - has weak encapsulation, which means that it can be used by any class.
2. Benefits of encapsulations –
1. Data becomes safe and secure
2. Class becomes more adaptable
3. Client class does not need to know the implementation of server class
4. Degree of coupling classes reduces
5. Re-usability of class increases
4. State and Behavior -
1. State and Behavior are linked with each other. Behaviors at any given time depends upon current state and state may be modified by behavior. Object intercommunication means team of object operates and communicates in synergy to implement the functionality of an application.
2. Category of behavior -
1. Client - Active and is instigator of interactions
2. Server - Passive and is target of message
3. Agent - Combines the characteristics of Client and Server. Agent dissociate client object from server object by introducing an indirection in the message propagation mechanism.
5. Benefits of Objects -
1. Manageable
2. Extensible
3. Complexity
4. Real World model
6. Implementation constraints -
1. Object persistence
1. Persistence Object
2. Non-persistence or transient or ephemeral Object
2. Broadcasting object - broadcasting is cloning of an object from one process to another process
3. Proxy object – proxy Objects is an alternative to object broadcasting. Local Proxy object automatically gets synchronized with remote object. Client interacts with proxy object, which hides all communication complexities.
7. Message -
1. Concept of message - foundation of communication relationship that dynamically/flexibly links the objects that were separated by de-composition process. It is responsible for the delegation of tasks, and guarantees that constraints are satisfied. Message flow can be of two type -
1. Control
2. Data
2. Categories of Message -
1. Constructor - Creates an object and fixes it initial stage
2. Destructor - Deletes an object
3. Selector - Returns a part of state of an object
4. Modifier - Changes a part of state of an object
5. Iterator - Visit the state of an Object or the content of data structure that includes several objects.
3. Message Synchronization -
1. Simple - Message from an active to passive object
2. Synchronous - Message from sender to recipient and sender is blocked till recipient accepts the message such as Payment. Synchronous message represents that a nested flow of control. This means that the operation that handles the message is completed before the client object regains the focus. Synchronous message is usually implemented as an operation call between two objects on the same thread.
3. Rendezvous - Recipient waits till it receives message such as Cashier ready to accept your money.
4. Timed - Sender waits for acknowledgement from recipient for it's message for a specified time such as Phone.
5. Asynchronous - Sender send the message without waiting for acknowledgement such as Post Mail. Asynchronous message indicates that the object that sends the message retains the focus of control in its thread while the supplier in its own thread is handling the message. Asynchronous messages are most frequently used in real-time system.
8. Interaction between objects is depicted by -
1. Collaboration
2. Sequence Diagram

1. Class and abstraction
1. Class diagrams depicts various level of abstractions in a system -
1. Single class
2. Large group of class
3. Relationship between classes
2. Class includes objects with similar -
1. properties
2. behavior
3. relationship to other objects
4. abstraction - in order to simplify things we use abstraction, which means focus from a specific angle on elements and neglecting others. Concept of abstraction generates Classes. From an analysis angle, it is abstraction of reality and static view from general standpoint.
2. Relationship
1. Relationships can be defined by following features -
1. Reflexive relationship  (both association and aggression) - different objects belonging to same class may need to send message to each other. Role names are used instead of associations.
2. Qualified associations (one to many, or many to many associations)
3. Constraints. It either limits the applicability of an association or gives more detail to its meaning.
4. Association classes in many to many relationships.
2. Relationship between classes -
1. Association is abstractions of object links, which tells us active/passive, role and multiplicity. The navigation direction of an association refers to the class or object that is capable of "knowing about" the other class or that is responsible for the collaboration. Navigation direction is shown by adding an arrowhead to point to the class that is "known about" by the other class. [PayRollManager]  writes [PayCheck], which means that PayRollManager creates PayCheck, or PayCheck is created by PayRollManager. Role names can be used instead of association names. Associations are found in the use-case scenarios or sequence or collaboration diagrams. Look at the argument specified in the message.
2. Aggression is strong and shows something "master and Salve" relationship and represented by diamond at the end. Initially associations are discovered and later they can be refined to aggression, depending the relationship i.e. strongly coupled. Aggregate object is made up of components and thus the relationship between it’s whole and part is called aggression. Aggregation (“has a”) is a special association that models a whole-part relationship between an aggregate and it’s part. Aggregation can have name, direction, navigation or a role names. It can be of following types -
1. Shared
2. Composition
3. Composition is even stronger type of aggression with filled diamond, which is used in strict parent and child relation.
4. Multiplicity can be -
1. One to one
2. One to many
3. Many to many
3. Parallels between class and object -
1. Since an object is an instance of a class, class may not change during the lifetime of an object.
2. Some classes such as abstract class may not be directly initiates.
3. Each link is an instance of an association. Link connects objects and association connects classes.
4. Link between two objects means that they know each other and may exchange messages.
3. Class hierarchy -
1. Generalization is transitive abstraction of sub-classes and generates super class. Multiple generalizations refer to multiple-inheritance. Generalization only pertains classes and can’t be instantiated via links – thus doesn’t have multiplicity. Also generalization is non-reflexive relationship such as class can't be derived from itself. Abstract class (opposite to concrete classes, which can instantiate an object) makes it possible to define common structure, relationships and behavior for several sub-classes. That’s why implementation is done sub-class levels. Inheritance depends upon polymorphism to work. Use generalization (super-class derived from the set of common sub-classes, by encapsulating the structure or/and behavior) and specialization (sub-class) to identify opportunities to use inheritance.  Generalization and specialization can be used to view abstraction and inheritance respectively. Steps in generalization
1. Check out the similarities
2. Create supper-class, by encapsulating the shared -
1.  structure or
2. behavior or
3. both
3. Sub-class from super-class
2. Specialization is more close to real world. Steps in specialization -
1. Examine candidate objects to determine whether they display specialized structure or behavior.
2. Create sub-classes that group the objects together on the basis of their specialization.
3. Difficulties of classification - Varies from view of point.
1. Generalization is not suitable for Metamorphosis such as stages of order processing. Metamorphosis is change in it’s from, structure, or function, which means object changing the class they belong to. Example is Employe has PayClassification and PayClassification is either Hourly, Salaried and Commissioned.
2. Levels in class hierarchy make it more difficult to understand and implement. Refining the hierarchy allows -
1. increase re-use
2. incorporate implementation classes
3. incorporate available class libraries
4. Inheritance – also referred as “is a” relationship, such as eagle is a bird. Inheritance is a mechanism to share structure, relationships and behavior between classes i.e. reuse of code. Super-class is inherited and child-class inherits. At times a class can act as both, super and child class. A sub-class can inherit attributes, interface and operations from its parent class. It satisfies two needs classification and construction.
1. General principal - inheritance is a technique offered by programming language to construct a class from one or more classes, sharing attributes, operations and sometimes constraints with in a hierarchy of classes.
2. Delegation - substitute to inheritance is possible, with selective inheritance, which is done manually.
3. Substitution - child class will inherit all the attributes and operations from its parent class. Later constraints can be put on the required operation. This pays path for Polymorphism.
5. Multiple inheritance - Multiple inheritance allow a class to inherit from more than one parent i.e. a sub-class has more than two parent super-classes. Inheritance copies the all the methods and attributes from parent to child having multiple inheritance. That’s why Java and ADA doesn’t have direct multiple inheritance. Problems are -
1. Complicates the model
2. Nonsensical subclass
3. Name clashes because of multiple copies of inherited features
4. Different concepts and roles with the same name leads to ambiguity
5. Code will be less maintainable
6. Normal tendency is to use multiple-inheritance, instead of aggregation, which should be avoided. An aggregation tree is composed of object instances that are all part of a composite objects. Where as an inheritance tree is made up of class that describe an object. Example - following objects
1. Window
2. WindowWithScrollbar
3. Scrollbar
1. Relationship will be -
1. Inheritance - Window “is a” WindowWithScrollbar.
2. Aggregation - WindowWithScrollbar “has a” Scrollbar.
6. Polymorphism and overloading - Polymorphism means that the implementation of an operation depends on the object’s target type. Principal is that each sub-class inherits the operation specification of its supper class, and sub-class has ability to modify the behavior of these inherited operations locally. Polymorphism ability to trigger different operations in response to the same message. This provides the scalability to child class. Mainly done to ease out maintenance, to reduce the hierarchy and improve dynamism. Not considered in Analysis.  Automatic selection of the correct code is the result of dynamic linking. Polymorphism exists when two conditions are met  -
1. An object from a sub-class acts as an object from a super-class.
2. Sub-class redefines one or more of the operations contained in the super-class.
3. Other features -
1. Advantage of substitution - this also conform substitution, which is good practice.
2. Operation overloading – ad hoc polymorphism. It is same operator name with different parameter. Overloading is resolved statically by compiler and has nothing to do with dynamic linking.
4. Five key concepts to be considered while making classes -
1. Avoid strong coupling (such as inheritance i.e. state, behavior and functionality) creates interdependency, which leads to -
1. Difficulty in extending
2. Bugs in one can affect others
3. Program becomes complex to understand and maintain
2. Avoid cohesion. Class, whose members are simply grouped together and have little in common are called coincidentally cohesive. Because elements of such classes don’t cohere to realize a purpose (i.e. one functionality), such classes are --
1. Difficult to understand
2. Difficult to use
3. Too complex to implement
3. Have sufficiency, which means class can function effectively.
4. Have completeness, which means that interface should have all the behavior of the class.
5. Primitiveness means that class should be simple and per the scope.
5. Classes can be found in use-cases by looking at entities, boundaries and control classes, which are all UML stereotypes -
1. Entities (contains information) - Entity is typically used to model business objects i.e. core concepts (independent and long lived information such as insurance policy) and it gets stored in the system. An entity class may be involved in many use-cases. An entity can be used among many applications. It can be of two type -
1. Internal
2. External
2. Boundaries (presentation and manipulation of information) - Applying the boundary stereotype to a class, means that the class will specialize in interfacing to the outside world such as TCP/IP protocol, Windows and dialogue box etc. The main purpose of a boundary class is to handle communication between the system’s external actors and its use-case i.e. internal workings. Since user-friendliness requirement means different to different people, prototyping and storyboarding should be carried out to clarify any vague requirements. Unlike the entity class, the boundary class is dependent on the system’s surroundings. Two functions are -
1. To model the system interface
2. To provide the interface to actor
3. Control classes (processing of information – when, what and who) - The control stereotype is used to handle a sequence of internal system operations i.e. use-case realization. This stereotype is also used to connect boundary objects with the correct entity objects. They represent dynamics of use-cases such as classes, which executes use-cases. Control classes are application dependent.
6. Steps to create class diagrams -
1. In use-case analysis, outline scenarios (just identification is sufficient and elaboration is not required) and interactions between the use-cases and the actors. Check out nouns (for candidate entity classes), verbs (for operations on candidate entity classes) and adjectives (for attributes). At this stage avoid computer implementation such as constructs, sub-routines, link-list etc.
2. Refinement i.e. dropping of class name - One term can refer to more than one class or several terms can refer to the same class. Filter the unsuitable nouns. Drop candidate class, if it’s name is reflecting a role or is vague. Also consider application requirement and scope. Some nouns will become attributes of other classes such as name, weight and height. If you find that two more classes express the same information, then choose the most descriptive one such as Passenger is more descriptive than Customer.  When candidate class name describes an operation, it is usually eliminated. However, is an operation has distinct feature, it can be identified as a class such as telephone call. The last reason for eliminating a candidate class is if it is an implementation construct. Any construct that is not part of the problem domain should be dropped during this early stage of analysis, although it might be needed later, during the design process.
3. Identify entity, boundary, and control classes
4. Group classes together to form packages by using stereotype of a package. Stereotypes are used to classify model elements - they were created in order to allow analysts to group classes and other model elements together. Classes that are classified with stereotypes belong together, because they share some general purpose. UML provides 40 predefined stereotypes. The main advantage of stereotypes is that, at a glance, they indicate the responsibility and the purpose of the class to which they are attached. Stereotypes name is placed between guillemets (i.e. << >>) or attaching an icon (i.e. graphical symbols).
5. Create class diagram
6. Document the classes
7. Suggested categories are -
1. Roles such as engineers
2. Events such as requests
3. Tangible things such as ATM Machines
4. Non-tangible classes such as idea
5. Interaction such as meetings
6. Organizations
7. Places
8. Stereotype for classes -
1. Actor
2. Boundary
3. Business Actor
4. Business Entity
5. Business Worker
6. Control
7. Domain
8. Entity
9. Interface
10. Table
11. View
9. Four ways to create messages in UML -
1. Interaction diagrams
2. Rational Rose Browser
3. Class diagrams
4. Class specification
10. vii) CRC (Class Responsibility Collaborator) cards, an alternative collaborative technique (i.e. business domain experts, analyst, object oriented designer and facilitator and observers - max six people), incremental and iterative technique to discover classes. It’s done after used-case and before object diagrams.
1. CRC has three sections -
1. Class - Class name
2. Responsibility - What class knows or does
3. Collaborator - Relationship with other classes
2. Agenda for CRC, which is normally focused on one scenario -
1. purpose of session
2. who will attend and what role
3. when and where
4. how to prepare for session

1. i) Object interaction diagrams that models dynamic behavior i.e. activity/process. Activity diagrams are used to model the business process or the flow of events through use-case. They can be used to implementation of an operation or to show how objects are affected by activities. They can also depict the parallel activities. It tells how use-case relates to each other (i.e. use-case workflow), easpecially parallelly.
2. ii) Notations -
1. (1) Start as filled circle
2. (2) Transition as arrow from first to second activity i.e. occurrence of an event(), which can be labeled. Event is shown on first activity and can be –
1. (a) A message being sent as a result of an operation call
2. (b) A condition being fulfilled
3. (c) A specific period of time elapsing
4. (d) An error occurring
3. (3) [Guard conditions]
4. (4) Action expression
5. (5) Send clauses (such as Printer.print(doc)) to send message between activities
6. (6) Activity as rectangle with rounded corners
7. (7) Inbound and outbound synchronization bars (along with description) as thick horizontal bar.
8. (8) Iterator as * and description are called multiple triggers, which are mapped in collaboration and sequence diagrams. Multiple triggers are usually associated with synchronization bars.
9. (9) Decision diamond
10. (10) End point as bulls eye, which is optional
11. (11) Dead-ends
12. (12) Swim lanes at the end, after tagging is over

State diagrams -

1. Event can cause the transition of objects from state to state (i.e. internal behavior of an objects), during the lifetime of an object. We can identify the state of an object by examining -
1. Operations
2. Value of attributes
3. Links to other classes
2. An action is best described as a task that takes place within a state. There are four possible actions within a state-
1. On entry
2. On exit
3. Do
4. On event
3. State diagrams can be used to examine classes (usually boundary and control classes) that display complex behavior and undergo transitions between several states. State diagram shows a great deal of details and thus very time consuming.
4. Notations -
1. Start as filled circle
2. Event/action is shown on all the transitions such as Age=60/Set leaving date/Notify pension department. Here action implies that the operation should take an insignificant amount and should be non-interruptible, which varies from system to system. Event is shown on first activity and can be –
1. Conditions becoming true
2. Time elapsing
3. Error arising
4. Message being received
3. [Guard conditions]
4. Activity as rectangle with rounded corners
5. Nested boxes
6. End point as bulls eye, which is optional

1. Since software development is an iterative process, quality needs to be checked at every step. Checking becomes important when we are switching over from analysis to design. A good model should –
1. Easy to communicate to the people involved. Use the words used in problem definition
2. Capture essential (i.e. core, which is internal to company and stays same in the long run) features of the problem domain. Relevant to problem domain
3. Easy to maintain i.e. easy to change and extend
4. Have clear purpose
5. Easy to verify and validate
1. Validation means that model conforms to customer’s expectation
2. Verification means that model can be tested. Faults can be isolated and rectified in the model itself.
2. Intelligent complex model –
1. Top view and refinements i.e. exploded view
2. Create sub-models by dividing large models into packages
3. Check consistency on an ongoing basis. Proactive measures –
1. Have naming guide lines
2. Regular meetings
3. Examine documentation
4. Dedicated cross-section team consisting of at the most 6 people –
1. Domain expert
2. Programmer
3. System designer
4. Tester
5. Customer
5. Ensure model coordination
6. Scenario walk-through
7. Homogenize the model means that a model may contain classes (usually candidate classes) with no real functionality or a class is handling too many tasks.
1. Homogenize means that all classes are –
1. Unique
2. Cohesive
3. Relevant
2. Homogenize entails –
1. Combining similar classes
2. Splitting classes, which have too many functions
3. Eliminating classes, which does not have a structure functionality or behavior or is not involved in any scenario