UNIT-I Introduction of Object Oriented Modeling - Prasad Mahale
Object Oriented Modeling and Reference Books: Design 1. Grady Booch, James Rumbaugh, Ivar Jacobson Unified Modeling Language User Guide, Addison- Wesley 2.Rambaugh, Object Oriented Modeling and Designing. PHI 3. Bouch. Object Oriented Analysis and Design with Applications. Addison Wesley. 4. Dan Pilone, Neil Pitman UML 2.0 in a Nutshell, O'Reilly 5. Schah, Introduction to OOAD with UML and Unified Process, TMH
a. What is object-oriented? The term Object Oriented means that we organize software as collection of discrete objects that incorporate both data structure and behavior. Characteristic of object Identity Data is quantized into discrete, distinguishable entity called object Classification A collection of objects with the same data structure (attributes, state variables) and behavior (function/code/operations) grouped into class.
Polymorphism:- Same operation may behave differently on different classes The ability to hide many different implementations behind a single interface Operation is an action or transfer that an object perform Specific implementation of an operation by a certain class is called method
Inheritance :- Sharing of attribute & operation among classes based on hierarchical relationship Automatic duplication of super class attribute and behavior definitions in subclass. Sharing of attribute & operation among classes based on hierarchical relationship
What is Object-Orientation - Example of Abstraction and Encapsulation Class Car Attributes Model Location Operations Start Accelerate Lawrence Chung CS6359.OT1: Module 1 6
b. What is Object oriented development? Modeling Concept, Not Implementation Object Oriented Methodology Methodology consist building a model of an application domain & then adding implementation detail to it during design of a system, it s known as object modeling technique (OMT) Steps:- 1. Analysis build a model of real-world situation sowing it s important properties Understand the problem statement Object in model is application domain concept, not computer implementation
2. System design make higher level decision about overall architecture Target system is organized into subsystem based on analysis structure &proposed architecture 3.Object design Build design model based on analysis model but contain implementation detail Focus on data structure & algorithm needed to implement each class 4. Implementation Object classes & relationships of object design are translated into a particular programming language, d/b & h/w implementation
b. What is Object oriented development? Three Models OMT methodology uses three kinds of models to describe a system: 1. Object model - describes the objects in the system and their relationships; 2. Dynamic model - describes the interactions among objects in the system; and 3. Functional model - describes the data transformations of the system.
Abstraction c. Object oriented themes Abstraction consist of focusing on the essential, inherent aspects of an entity and ignoring its accidental properties. Encapsulation Encapsulation ( information hiding) consists of separating the external aspects of an object, which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects. Combing Data and Behavior objects, not developers, decide how to carry out operations
Sharing The sharing of code using inheritance is one of the main advantage of OO language. Emphasis on Object Structure, Not Procedure Structure OOT stresses specifying what an object is, rather than how it is used. Synergy Identity, classification, polymorphism and inheritance characterize mainstream OO language. Each of these concepts can be used in isolation, but together they complement each other synergy.
Why We Model?
Modeling When you make a model you are making a mapping from the problem domain to a representation of the system you are modeling. Reality System When you work object-oriented the model tends to be close to the system modeled, and a program execution can be regarded as a simulation of the behavior of the system. Itntroduction to UML, page 14
Why Do We Model? Models give us a template that guides us in constructing a system. If you want to make a building you first make a blueprint of the building to make, in the same way you should make a model of the system you want to make. As the complexity of systems increases, so does the importance of good modeling techniques. Models help us visualize a system at different levels of abstraction, this makes it easier to manage complexity and to understand the system. Itntroduction to UML, page 16
We build models so that we can better understand the system we are developing. A model is an abstraction, before building any system a prototype may be developed. For example car, airplane, blueprints of machine parts, Plan for house construction etc., Models serve many purposes
Model consist of building abstraction of reality. Modeling achieves four aims. Modeling: 1. Helps us to visualize a system as we want it to be. 2. Permits us to specify the structure or behavior of a system. 3. Gives us a template that guides us in constructing a system. 4. Documents the decisions we have made. We build models of complex systems because we cannot comprehend such a system in its entirety.
The Importance of Modeling A model is a simplification of reality. A model provides the blueprints of a system. Models may encompass detailed plans, as well as more general plans that give a 30,000-foot view of the system under consideration. A good model includes those elements that have broad effect and omits those minor elements that are not relevant to the given level of abstraction. Every system may be described from different aspects using different models, and each model is therefore a semantically closed abstraction of the system. A model may be structural, emphasizing the organization of the system, or it may be behavioral, emphasizing the dynamics of the system.
1. Models help us to visualize a system as it is or as we want it to be. 2. Models permit us to specify the structure or behavior of a system. 3. Models give us a template that guides us in constructing a system. 4. Models document the decisions we have made. We build models of complex systems because we cannot cover such a system in its entirety.
Principles of Modeling 1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Choose your models well. 2. Every model may be expressed at different levels of precision. 3. The best models are connected to reality. 4. No single model is sufficient. Every nontrivial system is best approached through 5. A small set of nearly independent models.
1. The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped. Choose your models well.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best approached through
5. A small set of nearly independent models.
f. Object-Oriented Modeling In software, there are several ways to approach a model. The two most common ways are from an algorithmic perspective and from an object-oriented perspective. The traditional view of software development takes an algorithmic perspective. In this approach, the main building block of all software is the procedure or function. This view leads developers to focus on issues of control and the decomposition of larger algorithms into smaller ones
The contemporary view of software development takes an object-oriented perspective. In this approach, the main building block of all software systems is the object or class. Simply put, an object is a thing, generally drawn from the vocabulary of the problem space or the solution space; A class is a description of a set of common objects. Every object has identity (you can name it or otherwise distinguish it from other objects), state (there's generally some data associated with it), and behavior (you can do things to the object, and it can do things to other objects, as well).
Architecture of UML (4+1 view) software-intensive system demands that the system be viewed from a number of perspectives. Different stakeholders end users, analysts, developers, system integrators, testers, technical writers, and project managers each bring different agendas to a project, and each looks at that system in different ways at different times over the project's life.
A view model in system engg or s/w engg is framework A view is a representation of whole system for the perspective of a related set of concern. Different stakeholders always have different interest in s/w system. View are used to describe the system from the viewpoint of different stakeholders, such as end user, developers & project managers.
System's architecture artifact that can be used to manage these different viewpoints and so control the iterative and incremental development of a system throughout its life cycle. The architecture of a software-intensive system can best be described by five interlocking views. Each view is a projection into the organization and structure of the system, focused on a particular aspect of that system.
Use case view - It encompasses the use cases that describe the behavior of the system as seen by its end users, analysts, and testers. - Validation & illustration to show the design is complete. - This view doesn't really specify the organization of a software system - the static aspects of this view are captured in use case diagrams - the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams and activity diagrams.
Design view - It encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. - This view primarily supports the functional requirements of the system, meaning the services that the system should provide to its end users. - With the UML, the static aspects of this view are captured in class diagrams and object diagrams - the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams.
Process view - It shows the processes/workflows rules of a system & how those processes communication with each other. - This view primarily addresses the performance, scalability, and throughput of the system. - With the UML, the static and dynamic aspects of this view are captured in the same kinds of diagrams as for the design view. - Active classes that represent these threads and processes.
Implementation view - It encompasses the components and files that are used to assemble and release the physical system. - This view addresses the configuration management of the system's releases, made up of somewhat independent components and files that can be assembled in various ways to produce a running system. - With the UML the static aspects of this view are captured in component diagrams - the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams
Deployment view - It encompasses the nodes that form the system's hardware topology on which the system executes. - This view addresses the distribution, delivery, and installation of the parts that make up the physical system. - the static aspects of this view are captured in deployment diagrams - the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity diagrams.
RUP (Software Development Life Cycle) What is RUP? A software development approach that is iterative, architecture-centric and use-case driven RUP is process independent meaning that it is not tied to any particular software development life cycle. 1. Use case driven 2. Architecture-centric 3. Iterative and incremental
Use case driven means that use cases are used as a primary artifact for establishing the desired behavior of the system, for verifying and validating the system's architecture, for testing, and for communicating among the stakeholders of the project. Architecture-centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. Iterative process is one that involves managing a stream of executable releases, each new release is focused on attacking and reducing the most significant risks to the success of the project.
Iterative Development Phases: Inception: Understand what to build Vision, high-level requirements, business case Not detailed requirements Elaboration: Understand how to build it Baseline architecture, most requirements detailed Not detailed design Construction: Build the product Working product, system test complete Transition: Validate solution Stakeholder acceptance
As An Effective Process, the RUP: Provides guidelines for efficient development of quality software Provides suggested flows of activities and assignment of roles to artifacts Reduces risk and increases predictability Through iteration planning, risks aggressively attacked up front Captures and presents best practices very detailed. Learn from other s experiences The RUP is huge! Configurable to the project;. Contains disciplines addressing all stakeholder concerns Provides roadmap for applying tools it is NOT just a theory Suggests activity sequences; Adaptable for large and small projects. The RUP is a use-case driven, architecture-centric, iterative development process!
C O N T E N T S T R U C T U R E T I M E
Inception: Know What to Build Prepare vision document and initial business case Include risk assessment and resource estimate Develop high-level project requirements Initial use-case and domain models (10-20% complete) Manage project scope Reduce risk by identifying all key requirements Acknowledge that requirements will change Manage change, use iterative process
Elaboration: Know How to Build It Detail requirements as necessary (~80% complete) Less essential requirements may not be fleshed out Produce an executable and stable architecture Define, implement and test interfaces of major components Identify dependencies on external components and systems. Integrate shells/proxies of them. Some key components will be partially implemented Roughly 10% of code is implemented.
Drive architecture with key use cases 20% of use cases drive 80% of the architecture Design, implement and test key scenarios for use cases Verify architectural qualities Reliability: Stress test Scalability and Performance: Load test Continuously assess business case, risk profile and development plan
Construction: Build The Product Complete requirements and design model Design, implement and test each component Prototype system and involve end users Incrementally evolve executable architecture to complete system Build daily or weekly with automated build process Test each build Automate regression testing Load and stress test to ensure architectural integrity Deliver fully functional software (beta release) Includes training material, user and deployment documentation Produce release descriptions
Transition: Deploy to End Users Produce incremental bug-fix releases Update user manuals and deployment documentation Update release descriptions Execute cut-over Conduct post-mortem project analysis
Artifacts 1. Business model Establishes an abstraction of the organization 2. Domain model Establishes the context of the system 3. Use case model Establishes the system's functional requirements 4. Analysis model (optional) Establishes an idea design 5. Design model Establishes the vocabulary of the problem and its solution 6. Process model (optional) Establishes the system's concurrency and synchronization mechanisms 7. Deployment model Establishes the hardware topology on which the system is executed 8. Implementation model Establishes the parts used to assemble and release the physical system 9. Test model Establishes the paths by which the system is validated and verified
Other Artifacts 1. Requirements set describes what the system must do 2. Design set describes how the system is to be constructed 3. Implementation set describes the assembly of developed software components 4. Deployment set provides all the data for the deliverable configuration
Process Workflows The Rational Unified Process consists of nine process workflows. 1. Business modeling Describes the structure and dynamics of the organization 2. Requirements Describes the use case based method for eliciting requirements 3. Analysis and design Describes the multiple architectural views 4. Implementation Takes into account software development, unit test, and integration
Process Workflows 5. Test Describes test cases, procedures, and defect-tracking metrics 6. Deployment Covers the deliverable system configuration 7. Configuration management Controls changes to and maintains the integrity of a project s artifacts 8. Project Management Describes various strategies of working with an iterative process 9. Environment Covers the necessary infrastructure required to develop a system