Object-Oriented Analysis and Design (OOAD) PDF

Unit I Object Oriented Methodologies: Software System Life Cycle – Traditional cycle models – Object Oriented approach – Rambaugh et al Object Modeling Technique – Booch Methodology – Jacobsonet al methodology –Rational Unified Process (RUP) – Unified Modeling Language (UML) – UML Models.  INTRODU...

Unit I Object Oriented Methodologies: Software System Life Cycle – Traditional cycle models – Object Oriented approach – Rambaugh et al Object Modeling Technique – Booch Methodology – Jacobsonet al methodology –Rational Unified Process (RUP) – Unified Modeling Language (UML) – UML Models.  INTRODUCTION A Software development methodology is a series of processes like o System Analysis o Modeling o Design o Implementation o Testing o Maintenance There are two orthogonal views of software development  Traditional Technique: Focuses on data and functions  Object Oriented Methodologies: Focuses on objects that combine data and functionality. Object oriented systems development develop software by building objects that can be easily modified, replaced and reused. The advantages of object oriented systems are  Easier to adapt  Easier to maintain  Promote greater design and code reuse  Creates modules of functionality  What is OOAD? Analysis is the process of investigation of the problem and the requirements than finding its solution. Analysis is classified as o Requirement Analysis o Object Oriented Analysis In object Oriented analysis , finding and describing the objects or concepts in the problem domain is done. Example: During analysis the concepts are identified in the flight information system i.e Plane, Flight, Pilot  Object Oriented Design Design is the process of finding a conceptual solution that fulfills the requirements than implementing it.Design is classified into o Database design o Object Oriented Design In Object Oriented design, software objects are defined and collaborated to fulfill the requirements. Example In flight information System plane is a software object having  Attribute- TailNumber   Method- getFlightHistory  SOFTWARE SYSTEM LIFE CYCLE  The software development process consists of analysis, design, implementation, testing and refinement phase which is used to transform the user needs to software solution that satisfies those needs.  Software development can be viewed as a process. The development itself is a process of change, refinement, transformation or addition to the existing product.  Within the process, it is possible to replace one sub process with a new one, as long as the new process has the same interface as the old one.  With this method of change, it is possible to adapt to a new process.  The process can be divided into small, interacting phases called sub processes.  Each sub processes must be clearly defined so that it allows each activity to be performed independently as of other sub processes. Each sub processes must have the following behavior: o A description in terms of how it works o Specification of the input required for the process o Specification of the output to be produced The software development process can be viewed as a series of transformations where the output of one transformation becomes of the input of the subsequent transformation.  Transformation 1 (Analysis): This translates the users’ needs into system requirements and responsibilities. This always gives an insight to the users’ requirements.  Transformation 2(design): This begins with a problem statement and ends with a detailed design that can be transformed into an operational system. This transformation includes the bulk of the software development activity, including the definition of how to build the software, its development, and its testing. It also includes the design descriptors, the program and the testing materials.  Transformation 3(Implementation): This refines the detailed design into the system deployment that will satisfy the users’ needs. It represents embedding the software product within its operational environment. Fig 1: Software process reflecting transformation from needs to a software product that satisfies those needs  TRADITIONAL CYCLE MODELS  Waterfall model  This early life cycle model represents the stages of development as a straightforward sequence, where one stage must be completed before the next begins.  It was the first model to identify the different stages that make up the system development process, and its simplicity has made it a useful model for many years.  However, the waterfall model is not really a true reflection of what actually happens in system development, since it does not emphasize the need to iterate over the stages. Fig 2: Waterfall model The main concept of this model is that only when one development level is completed will the next one be initiated. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Advantages – The Waterfall method is also well known amongst the software developers therefore it is easy to use – Works well for smaller projects where requirements are very well understood – Cost effectiveness: Time spent early in the software production cycle can lead to greater economy at later stages Disadvantages –The crucial disadvantage of this model is that testing is understood as a “one time” action at the end of the project just before the release the operation. The test is seen as a “final inspection”, an analogy to a manufacturing inspection before handling over the product to the customer. –High amounts of risk and uncertainty –Inflexible –Poor model for complex and object-oriented projects In summary, the Waterfall Model should use in projects with clearly and deeply understood of project requirements, design, technical tools and infrastructures.  V-model  This is a variation of the waterfall, where the stages are visualized in the form of the letter 'V'. It emphasizes how later stages of development are related to earlier stages.  For example, how testing should be derived from the activities that are carried out during requirements and analysis. Fig 3: V Model  The development process proceeds from the upper left point of the V toward the right, ending at the upper right point.  In the left-hand, downward-sloping branch of the V, development personnel define business requirements, application design parameters and design processes. At the base point of the V, the code is written.  In the right-hand, upward-sloping branch of the V, testing and debugging is done. The unit testing is carried out first, followed by bottom-up integration testing.  The extreme upper right point of the V represents product release and ongoing support. Like in Waterfall- Model each phase must be completed before the next phase begins, V-model actually is a modified version of a Waterfall-Model.  The V-model ordains that the code testing documentation is written in tandem with the development phases that means, for instance, the integration tests should be documented as and when the high level design is finalized and the unit tests should be ready as and when the detailed specifications are laid down.  In this model testers should be involved in reviewing development information as soon as possible.  Like Waterfall-Model testing process and fixing faults can be done in any stage in the life cycle, but the cost of finding and fixing faults increases dramatically as development progresses. Advantages – Due to the fact that in the V-Model defects are being repair short time after they have been detected, it is cheaper to fix them – The model has a reputation of a very good base for the partitioning of testing; all the participants in development of a system have a responsibility for quality assurance and testing. – Testing activities like requirements, test designing happens well before coding. This fact saves a lot of time and also helps in developing a very good understanding of the project at the initial stage. – The objectives of testing are changing , and specific for each test level Disadvantages – The V-Model is very rigid and the least flexible, it means that if one of the requirements are changing, the tester should update the test documentation as a whole – This model applicable mostly to big companies because the model needs lot of resources – The amount and the intensity of the test levels should be tailored according to the specific needs of the project In summary: In the V-Model the place of testing in development process is critical. The fault finding occurs in early stage of the development process which provides the cheaper alternative for fixing it.  Spiral model  The spiral model is mostly used in large projects. For smaller projects, Agile concept is more appropriate.  This model of development combines the features of the prototyping model and the waterfall model.  The spiral model was defined by Barry Boehm in his article “A Spiral Model of Software Development and Enhancement” (1985).  This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. Spiral model is an evolutionary version of incremental prototyping. Fig 4: Spiral Model  Incremental development means that the project is not done by (possibly large) pieces, but as a series of smaller developments and deliveries.  Incremental models try to reduce the risk of developing the wrong system by delivering useful parts of the system early and getting customer feedback.  System functionality and reliability requirements will grow over the time, from an early version only for the development or for users, to version released to final customers later. Advantages – Spiral Life Cycle Model is a very flexible model. Development phases can be determined by the project manager, according to the complexity of the project. – Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier. – Good for large and mission-critical projects. – Software is produced early in the software life cycle. Disadvantages – Doesn’t work well for smaller projects. – Evaluating the risks involved in the project can shoot up the cost and it may be higher than the cost for building the system.  – Spiral model is much customized for every project. – Risk analysis requires highly specific expertise. In summary: It serves as the best option for businesses with volatile business goals but where there is a need for a prototype to handle the complexities in the business procedures.  Agile Model  Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.  Agile as the name refers implies something to do very quickly. Hence, Agile Testing refers to validate the client requirements as soon as possible and make it customer friendly.  Agile practices are specially tailored to eliminate all kinds of waste manifesting in a product life cycle, but more especially, improving the quality of developed product is a major goal threaded into most of those practice. Fig 5: Agile Model  There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks.  Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. In Agile testing as soon as the build is out, testing is expected to get started and report the bugs quickly if any found.  There are some accepted properties to Agile Model, for example:  -Short release cycles- agile development can’t be called agile unless it is done in short repetitive iterations. -Customer involvement. Tester should to provide his thoughts on the client requirements rather than just being the audience at the other end. – Responding to change – agile development is focused on quick responses to change and continuous development. – Individuals and interactions over processes and tools Advantages – Saving of time and money. – Focus more on the application rather than documenting things. – Daily meetings and discussions for the project following Agile model can help to determine the issues well in advance and work on it accordingly. – Requirements changing even in late stage of development – The end result is the high quality software in least possible time duration and satisfied customer. Disadvantages – The project can easily get taken off track if the customer representative is not clear what final outcome that they want. – There is lack of emphasis on necessary designing and documentation. – User involvement is often a potential problem especially in big and complex projects – Agile processes are really only applicable for products where reliability is not very critical.  In summary: After all strengths and weaknesses I have come to the conclusion that with the quicker development, testing and constant feedback from the user, the Agile methodology becomes the appropriate approach for the projects to be delivered in a short span of time.  Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods.  Prototyping  In the prototyping life cycle, implementation takes place early in the development process.  The working model produced is subsequently refined and enhanced during a series of iterations until it is acceptable to the client.  Incremental development  In this life cycle model the system is partitioned according to areas of functionality. Each major functional area is developed and delivered independently to the client.  For example, in the bike hire system, tasks relating to issuing a bike might be developed and delivered, followed by returning a bike and then maintaining customer records.  Iterative development  This approach is closely related to the spiral model and to prototyping.  A skeleton version covering the complete functionality of the system is produced and then refined as development progresses.  RAMBAUGH ET AL OBJECT MODELING TECHNIQUE  Rambaugh et al method is well suited for describing the object model or the static structure of the system.  The Object Modeling System(OMT) presented by Jim Rumbaugh and his co workers describes a method for the analysis, design and implementation of a system using an object-oriented technique.  OMT is fast, intuitive approach for identifying and modeling all the objects making up a system.  The dynamic behavior of objects within a system can be described using OMT dynamic model.  This helps to specify the detailed state transitions and their descriptions within a system.  A process description and consumer producer relationships can be expressed using OMT’s functional model. OMT consists of four phases o Analysis: The results are objects and dynamic and functional models. o System Design: The results are a structure of the basic architecture of the systems along with high level strategy decisions. o Object Design: This phase produces a design document, consisting of detailed objects static. dynamic and functional models. o Implementation: This activity produces reusable, extendible and robust code. OMT separates the modeling into three different parts: o Object Model, presented by the object model and data dictionary. o Dynamic Model, presented by the state diagrams and the event flow diagram. o Functional Model, presented by the data flow and constraints  THE OBJECT MODEL  It describes the structure of objects in a system: their identity, relationships to other objects, attributes and operations.  The object diagram contains classes interconnected by association lines.  Each class represents a set of individual objects.  The association lines establish relationships among the classes.  Each association line represents a set of links from the objects of one class to the objects of other class. Fig 6: OMT object model of a bank system  THE OMT DYNAMIC MODEL  OMT provides a detailed and comprehensive dynamic model. It is a network of states and events.  Each state receives one or more events, at which times it makes one or more transition to the next state.  The next state depends on the current state as well as the events.  Fig 7: State transition diagram for the bank application user interface  OMT FUNCTIONAL MODEL  The OMT data flow diagram (DFD) shows the flow of data between different processes in a business.  An OMT DFD provides a simple and intuitive method for describing business processes without focusing on the details of computer systems.  DFD uses four main symbols  The process is any function being performed; example ,verifying the password or PIN in ATM system.  The data flow shows the direction of data element movement; for eg.PIN code.  The data store is a location where data are stored; for eg,account is a data store in the ATM example.  The external entity is a source or destination of a data element; for eg, the ATM card reader.  Overall, the Rumbaugh et al. OMT methodology provides one of the strongest tool sets for the analysis and design of object oriented systems.  THE BOOCH METHODOLOGY  The booch methodology is a widely used object-oriented method that helps you design your system using the object paradigm. It covers analysis and design phases of an object -oriented system.  The booch method consists of the following diagrams: o Class Diagram o Object Diagram o State transition Diagram o Module Diagrams o Process Diagrams  o Interaction Diagrams  The booch method prescribes a macro development and a micro development process.  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 macro process is technical management of the system.  In macro process the traditional phases of analysis and design to a large extent are preserved.  The macro development consists of the following steps:  Conceptualization: During Conceptualization , you establish the core requirements of the system. Establish a set of goals and develop a prototype to prove the concept  Analysis and Development of the model: In this step, you use the class diagram to describe the roles and responsibilities objects carry out in performing the desired behavior of the system. Then, you use the object diagram to describe the desired behavior of the system in terms of scenarios, or alternatively use interaction diagrams.  Design or create the system architecture: In the design phase, you use the class diagram to decide what classes exists & how they relate to each other. Next you use the object diagram to decide what mechanism are used to regulate how object collaborate. Then, you use the module diagram to map out where each class and object should be declared. Finally, you use the process diagram to determine to which processor to allocate a process.  Evolution or Implementation Successively refine the system through many iterations. Produce a stream of software implementations(or executable releases), each of which is a refinement of the prior one. ◦ Maintenance: Make localized changes to the system to add new requirements and eliminate bugs.  Fig 8: Object Modeling using Booch notation  The Micro Development process  Each macro development process has its own micro development processes. It 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: o Identify classes and objects o Identify class and object semantics o Identify class and object relationships. o Identify class and object interfaces and implementation. Fig 9: An alarm class state transition diagram with booch notation   THE JACOBSON ET AL. METHODOLOGIES  The Jacobson et al. methodologies (e.g., object oriented Business Engineering (OOBE), object oriented Software Engineering (OOSE), and Objectory) cover the entire life cycle and stress traceability between the different phases, both forward and backward.  This traceability enables reuse of analysis and design work, possibly much bigger factors in the reduction of development time than reuse of code.  At the heart of their methodologies is the use case concept, which evolved with Objectory (Object Factory for Software Development).  Use cases  Use cases are scenarios for understanding system requirements. A use case is an interaction between users and a system. The use-case model captures the goal of user and the responsibility of the system to its users Fig 10: Some uses of a library  In the requirements analysis, the use cases, are described as one of the following : o Nonformal text with no clear flow of events. o Text, easy to read but with a clear flow of events to follow (this is a recommended style). o Formal style using pseudo code.  The use case description must contain: o How and when the use case begins and ends. o The interaction between the use case and its actors, including when the interaction occurs and what is exchanged. o How and when the use case will need data stored in the system or will store data in the system. o Exceptions to the flow of events. o How and when concepts of the problem domain are handled.  Use cases could be viewed as concrete or abstract. An abstract use case is not complete and has no actors that initiate it but is used by another use case.  This inheritance could be used in several levels. Abstract use cases also are the ones that have uses or extend relationships.  Object-Oriented Software Engineering: Objectory  Object-oriented software engineering (OOSE), also called Objectory, is a method of object-oriented development with the specific aim to fit the development of large, real-time systems.  The development process, called use-case driven development, stresses that use cases are involved in several phases of the development , including analysis, design, validation, and testing.  The use-case scenario begins with a user of the system initiating a sequence of interrelated events.  The system development method based on OOSE, Objectory, is a disciplined process for the industrialized development of software, based on a use-case driven design.  It is an approach to object-oriented analysis and design that centers on understanding the ways in which a system actually is used.  Objectory is built around several different models: o Use case-model.The use-case model defines the outside (actors) and inside (use case) of the system's behavior. o Domain object model. The objects of the "real" world are mapped into the domain object model. o Analysis object model. The analysis object model presents how the source code (implementation) should be carried out and written. o Implementation model. The implementation model represents the implementation of the system. o Test model. The test model constitutes the test plans, specifications, and reports.  Object-Oriented Business Oriented Business Engineering  Object-oriented business engineering (OOBE) is object modeling at the enterprise level.  Use cases again are the central vehicle for modeling, providing traceability throughout the software engineering processes.  Analysis phase  The analysis phase defines the system to be built in terms of the problem-domain object model, the requirements model, and the analysis model.  The analysis process should not take into account the actual implementation environment.  This reduces complexity and promotes maintainability over the life of the system, since the description of the system will be independent of hardware and software requirements.   The analysis process is iterative but the requirements and analysis models should be stable before moving on to subsequent models.  Jacobson et al. suggest that prototyping with a tool might be useful during this phase to help specify user interfaces.  Design and implementation phases  The implementation environment must be identified for the design model.  This includes factors such as Database Management System (DBMS), distribution of process, constraints due to the programming language, available component libraries, and incorporation of graphical user interface tools.  It may be possible to identify the implementation environment concurrently with analysis.  The analysis objects are translated into design objects that fit the current implementation environment.  Testing phase.  Finally, Jacobson describes several testing levels and techniques. ◦ The levels include unit testing, integration testing, and system testing  RATIONAL UNIFIED PROCESS (RUP)  A life cycle provides a high-level representation of the stages that a development project must go through to produce a successful system, but it does not attempt to dictate how this should be achieved, nor does it describe the activities that should be carried out at each stage.  A development method, 1 on the other hand, is much more prescriptive, often setting down in detail the tasks, responsibilities, processes, prerequisites, deliverables and milestones for each stage of the project.  Over the past decade, there have been a number of object oriented development methods, such as Responsibility-Driven Design, Object Modeling Technique and Open.  It is beyond the scope of this book to describe these in detail, but you can find references to all of them at the end of the chapter and in the bibliography.  Nowadays, almost all object-oriented projects use the Unified Modeling Language as the principal tool in their development process.  Use of the UML has been approved by the Object Management Group (OMG), which controls issues of standardization in this area. This has resulted in conformity between projects in terms of notation and techniques. However, UML is simply a notation or language for development; it is not in itself a development method and does not include detailed instructions on how it should be used in a project.  The Unified Software Development Process and this generic method has been adopted and marketed by the Rational Corporation under the name of the Rational Unified Process (RUP).  Short for Rational Unified Process, a software development methodology from Rational. Based on UML, RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development.  Inception-- In this stage, the projects business case is stated and the team decides if the project is worth doing or if it is even possible. It is important to the process to first formulate the scope of the project and also determine what resources will be needed.  Elaboration -- In this stage, the developers take a closer look at the project to determine its architecture foundation and to evaluate the architecture in relation to the project. This stage is important to the RUP because it is here that developers analyze the risks associated with changing the scope of the project or adding new technologies along the way.  Construction-- In this stage, the development of the project is completed. The application design is finished and the source code is written. It is in this stage that the software is tested to determine if the project has met its goal laid out in the inception phase.  Transition -- In this stage, any fine-tuning is performed. Any final adjustments can be based on user feedback, usability or installation issues. Fig 11: RUP Phases  RUP incorporates not only modelling techniques from the UML, but also guidelines, templates and tools to ensure effective and successful development of software systems.  The tools offered by RUP allow a large part of the development process to be automated, including modelling, programming, testing, managing the project and managing change.  RUP is based on the following six 'Best Practices' which have been formulated from experience on many industrial software projects: o Develop software iteratively o Manage requirements o Use component-based architectures o Visually model software o Verify software quality o Control changes to software.  Develop software iteratively  It is built on the central concept of iterative development and each of its phases defines a series of activities that may be performed once or a number of times.  Each iteration is defined as a complete development loop resulting in the release of an executable product that is a subset of the final system.  In this way RUP supports incremental development- the frequent release of small packages of software that gradually build up to become the final system.  Iteration and incremental development encourage involvement and feedback from clients and users; they make it easier to cope with changes, and reduce the risk factors associated with any development project.  Manage requirements  RUP offers sound support for eliciting, organizing and recording requirements.  Precise documentation of requirements facilitates traceability through the development process, which enhances the quality of the final system.  The emphasis on the activities that take place early on in the life cycle provides a sound foundation for the later stages and results in systems that are robust, reliable and meet the needs of their users.  Use component-based architectures  RUP prescribes the early identification and development of a system structure that is at the same time robust enough to ensure system reliability, and flexible enough to accommodate changes.  This is achieved through the use of components subsystems that each have a single, well-defined function.  RUP describes how to construct an architecture combining both new and previously existing components, thus encouraging the reuse of software as part of the development process.   Visually model software  RUP is based around the Unified Modeling Language (UML) as a vehicle for development.  UML has become an industry standard, and incorporates a wide range of techniques and tools to support developers.  The techniques offered by UML bring with them all the advantages of visual modeling.  For example, UML diagrams facilitate communication between developers and users and between members of the development team, they offer a number of different views of the system which combine to give a complete picture, they help developers to decompose the problem into smaller, more manageable chunks, and they provide a means of abstraction, concentrating on important information while hiding details that are currently irrelevant.  Verify software qualities  RUP provides the techniques to support quality assessment of functionality, reliability and performance throughout the development process.  The RUP approach to quality is based on objective measures and criteria for success; it involves all members of the development team and applies to all the activities that are carried out as part of the system development.  Control changes to software  Changes are the norm in a software development project, so an effective development process must be able to monitor and control them.  RUP provides tools to do this, and also supports the work of developers by offering protection in one area of development from changes that occur in another.  RUP is an increasingly popular approach to developing software systems, and is already laying claim to be the industry standard.  UNIFIED MODELING LANGUAGE (UML)  The Unified Modelling Language (UML) The Unified Modeling Language, or UML, is a set of diagrammatic techniques, which are specifically tailored for object-oriented development, and which have become an industry standard for modelling object-oriented systems.  The UML grew out of the work of James Rumbaugh, Orady Booch and Ivor Jacobson, and has been approved as a development standard by the Object Management Group.  Modelling Architects and engineers have always used special types of drawing to help them to describe what they are designing and building.  In the same way, software developers use specialized diagrams to model the system that they are working on throughout the development process.  Each model produced represents part of the system or some aspect of it, such as the structure of the stored data, or the way that operations are carried out.  Each model provides a view of the system, but not the whole picture.  As an example, let us consider a small girl, Jane, and imagine that we have a photograph of her. The photograph is one possible model of the real-life Jane; it tells us what she looks like, and may give some idea of her character. Figure 1. 4 shows two more possible models of the real-life Jane. Fig 12 :different models showing different information about one real life person  Unlike a photograph, the family tree in Figure 12(a) tells us nothing about Jane~ appearance, but it does provide information about her family. We can see that she has four brothers and is the youngest child; we also discover the first names of Jane's parents and siblings. The family tree is a graphical, diagrammatic model. Figure 12(b), on the other hand, is a textual model; it tells us some details about Jane, her birth date, address, school and which class she is in. Each model (the photograph, the family tree and the piece of text) tells us something about Jane, but we can only get all the information by looking at all the models (in fact we would need many more detailed models to get a complete picture of her).  The characteristic of a model to provide some but not all the information about the person or thing being modelled is known as abstraction. We can say that each of the models in Figure 12 is an abstraction of the real-life Jane, focusing on certain aspects of her and ignoring other details.  In the same way, each of the modelling techniques in the Unified Modeling Language provides a particular view of the system as it develops; each UML model is an abstraction of the complete syst em.  Abstraction is a very important tool in modeling any sort of Software system because typically the problems developers have to deal with are much too complex for one developer to hold all the details in his head at once.  Abstraction provides a means of concentrating on only those aspects of the system that are currently of interest, and putting other details to the side for the time being.  Another, equally important tool for modelling software systems is decomposition. This is the breaking down of a large, complex problem or system into successively smaller parts, until each part is a 'brain-size' chunk and can be worked on as an independent unit.  Traditionally software systems used to be decomposed according to their f u n c t i o n s - the tasks that the system had to carry out.  Initially, the models that are constructed using the techniques provided by the UML help the developer to impose a coherent structure on the information gathered from clients and users.  One of the principal uses of the models is as a basis for discussions, Since talking about the system as represented helps to identify gaps and inconsistencies in the information.  As the project progresses, the original models are enhanced with details relating to design and implementation issues, so that eventually they become a blueprint for the development of the system. Table 1 : The principal UML diagram with brief descriptions   UML MODELS  The UML is not a development method since it does not prescribe what developers should do, it is a diagrammatic language or notation, providing a set of diagramming techniques that model the system from different points of view.  The 4 + 1 view. The authors of UML, Booch (1999), suggest we look at the architecture of a system from five different perspectives or views: o The use case view o The design view o The process view o The implementation view o The deployment view.  This is known as the 4 + 1 view (rather than the 5 views) because of the special role played by the use case view. o The use case view of the system is the users' view: it specifies what the user wants the system to do; The use case view describes the external behaviour of the system. o The design view (sometimes called the logical view) describes the logical structures required to provide the functionality specified in the use case view. The design view describes the classes (including attributes and operations) of the system and their interactions. o The process view is concerned with describing concurrency in the system.  The implementation view describes the physical software components of the system, such as executable files, class libraries and databases.  The deployment view of the system describes the hardware components of the system such as PCs, mainframes, printers and the way they are connected.  This view can also be used to show where software components are physically installed on the hardware elements. Deployment diagrams describe this view of the system. Not all of these views will be required for every system.  For instance, if your system does not use concurrency, you will not need a process view. If your system runs on a single machine, you will not need the deployment view or the component view, as all of the software components will be installed on one machine.  The 4 + 1 view gives us five different ways of viewing a system and is supported in UML by modelling techniques to capture each view.  Just as a photograph, family tree and description give us different views of a person, the UML views show us a system from different points of view.  Each one offers a different perspective; no one gives us the whole picture. To gain complete understanding of the system all of the views must be considered.  It is very important to distinguish between the UML model. Different diagrams are used for different type of UML modeling. There are three important type of UML modelings:  Structural modeling Structural modeling captures the static features of a system. They consist of the followings: o Classes diagrams o Objects diagrams o Deployment diagrams o Package diagrams o Composite structure diagram o Component diagram  Structural model represents the framework for the system and this framework is the place where all other components exist. So the class diagram, component diagram and deployment diagrams are the part of structural modeling.  They all represent the elements and the mechanism to assemble them.  But the structural model never describes the dynamic behavior of the system. Class diagram is the most widely used structural diagram.   Behavioral Modeling:  Behavioral model describes the interaction in the system. It represents the interaction among the structural diagrams. Behavioral modeling shows the dynamic nature of the system. They consist of the following: o Activity diagrams o Interaction diagrams o Use case diagrams  All the above show the dynamic sequence of flow in a system.  Architectural Modeling:  Architectural model represents the overall framework of the system. It contains both structural and behavioral elements of the system.  Architectural model can be defined as the blue print of the entire system. Package diagram comes under architectural modeling. Fig : UML diagrams