This action might not be possible to undo. Are you sure you want to continue?
design your system using the object paradigm. It covers the analysis and design phases of an object-oriented system. It concentrates on static model ; the dynamic model is constructed for a few object. It promotes on object decomposition showing that at the design level object orientation can be used even if the implementation language is not object oriented. Booch sometimes is criticized for his large set of symbols. Only when you are ready to generate code, you need to add design symbols. The Booch OOD describes diagrams at two levels: Design Level: Class diagrams ± shows existence of classes and their relationships in the logic design of the system. It represents the class structure. y Object diagrams - shows existence of objects and their relationships in the logic design of the system. It represents the scenario. y State transition diagrams - represents the state space of an instance of a given class. y Interaction diagrams ± Used to trace the execution of a scenario in the same context as an object diagram Implementation Level: y Module diagrams ± Shows the allocation of classes and objects to modules in the physical design of the system. It represents the module architecture. y Process diagrams - Shows the allocation of classes and processes to processors in the physical design of the system. It represents the process architecture. Notations Important notations in Class diagram and Object diagram y
Abstract Class Icon Association Inheritance
Object notation has (aggregation) using (client-supplier relationship)
Important notations in Interaction diagram Entity1 Entity2 Message1 Message2 Entity3 Message3 Important notations in State transition diagram State name actions event/action . For eg: Class Taurus is subclass of the class Ford.Arrows represent specialization.Fig 1: Object modeling using Booch notation .
a stimulus causes the class to perform some processing. the alarm silenced state can be changed to alarm sounding state and vice versa. followed by a transition to another state . In this case. For eg: .Fig 2: An alarm class state transition diagram with Booch notation. This diagram can capture the state of a class based on a stimulus. Important notations in Module diagram Name Name Name name Main Program Specification Body Subsystem Important notations in Process diagram .
Processor Device Process1 Process2 «««. which could look blurry to an outside viewer. The micro process is a description of the dayto-day activities by a single or small group of software developers. Data dictionary. I. The Micro Development Process Each macro development process has its own micro development processes. To discover the abstractions of the system. since the analysis and design phases are not clearly defined. To establish the behavior and attributes of each abstraction identified in the previous phase To allocate the responsibilities for different system behaviors. . which acts as the central repository for the abstractions of the system and establishes a common vocabulary throughout the project. The stream of scenarios and architectural products emerged and refined by the macro process largely drives the Micro Development Process of object oriented development. 2. apply techniques of use case analysis. Apply the techniques of behavior analysis to identify abstractions that are directly related to the system function points. y From the scenarios of macro process . To establish the boundaries of the problem To devise an object oriented decomposition of the system under development. The Booch methodology prescribes a macro development process and a micro development process. It offers a framework for evolving the architecture and exploring alternative designs. The micro development process consists of the following steps: 1.. Identify classes and objects: Purposey y y Product ± y Activities ± Apply classical approach to OOA to generate a set of candidate classes and objects. Identify class and object semantics: y y Purposey y Products ± y Refinement of data dictionary to attach responsibilities.
To specify associations among classes (including aggregation and inheritance) 4. 3. Storyboarding ± Represents a top ± down identification of semantics and addresses strategic issues y Isolated class design .y y Activities ± Specification for each abstraction to state the named operations that form protocol of each class Object diagrams and Interaction diagram to capture the semantics of the scenarios that derive from the macroprocess.Represents a bottom ± up identification of semantics y Pattern Scavenging ± Recognizes the importance of commonality and represents opportunities for reuse Identify class and object relationships: y Purposey y Products ± y y y Activities ± y y y Specification of associations Identification of various collaborations (dynamic semantics) Refinement of associations Class diagram Object diagram Module diagram To solidify boundaries of and to recognize the collaborators with each abstraction. Refined data dictionary to include new classes Module diagrams Pseudocode Class diagrams (static semantics) Interaction diagrams (dynamic semantics) To create representations of abstractions in tangible forms Avoids premature implementation decisions . Identify class and object interfaces and implementation: Purposey y Products ± y y y y y Activities ± y Selection of Data structures and algorithms that provide semantics of abstraction.
(Function point is a unit of measurement to express the amount of business functionality an information system provides to a user. The primary concern of the macro process is technical management of the system. code walkthroughs. It insists a number of measurable products and activities that permit the development team to meaningfully assess risk for making early corrections to the micro process. you use the class diagram to describe the roles and responsibilities objects are to carry out in performing the desired behavior of the system. This is an incremental development process and includes configuration management. Design or create the system architecture: This step establishes common tactical policies. In domain analysis. The main activities include domain analysis and scenario planning. establish the core requirements of the system. each growing in its functionality. you use the object diagram to describe the desired behavior of the system in terms of scenarios or. In scenario planning identify the function points and for each function point identify the scenarios. 3. quality and completeness. quality assurance and documentation. Conceptualization: During conceptualization. It determines how well the project corresponds to the requirements set for it and whether it is produced on time. use the interaction diagram to describe behavior of the system in terms of scenarios. The macro development process consists of the following steps: 1. tactical design and release planning. This step is uncontrolled to allow unrestrained innovation. Establish a set of goals and develop a prototype to prove the concept. In the design phase. It focuses upon the two manageable elements ± risk and architectural vision that have the greatest impact on schedule. Next. Tactical design includes making decisions about tactical policies and release planning activity identifies a controlled series of architectural releases. Architectural planning includes devising layers and partitions for logical decomposition. Then. alternatively. The main activities include architectural planning.) In this step. you use the object diagram to decide what mechanisms are . Analysis and development of the model: This step provides a model of the system behavior. The Macro Development Process The macro process serves as a controlling framework for the micro process and can take weeks or even months. you use the class diagram to decide what classes exist and how they relate to each other. 2. identify the classes and objects common to a domain.Identify the classes and objects Identify the classes and objects semantics Specify Class and object interface and implementation Identify the classes and objects relationships Booch Micro Development Process II.
Establishment of Core Requirements CONCEPTUALIZATION Developing a model of the desired behavior ANALYSIS Creation of Architecture DESIGN Managing Post Delivery Evolution MAINTENANCE Evolving the Implementation EVOLUTION Booch Macro Development Process THE JACOBSON ET AL. object-oriented Software Engineering (OOSE). you use the module diagram to map out where each class and object should be declared. It includes a requirements.g.OOSE Object-Oriented Software Engineering (OOSE) is a software design technique that is used in software design in object-oriented programming. Manage a punch list to collect bugs and enhancement requirements so that they can be prioritized for future releases. each of which is a refinement of the prior one. 5. OOSE is developed by Ivar Jacobson in 1992. both forward and backward. determine the schedules for multiple processes on each relevant processor.used to regulate how objects collaborate. The Jacobson et al. Also. Evolution or implementation: Successively refine the system through much iteration. a design. OOSE is the first object-oriented design methodology that employs use cases in software design. such as Booch and OMT. Maintenance: Make localized changes to the system to add new requirements and eliminate bugs. methodologies (e. At the heart of their methodologies is the use-case concept. OOSE is one of the precursors of the Unified Modeling Language (UML). This traceability enables reuse of analysis and design work. object-oriented Business Engineering (OOBE). you use the process diagram to determine to which processor to allocate a process. 4. The main activities include application of microprocess and change management. an implementation and a testing model. Finally. which evolved with Objectory (Object Factory for Software Development). Produce a stream of software implementations (or executable releases). an analysis. METHODOLOGIES Object-Oriented Software Engineering . Then. possibly much bigger factors in the reduction of development time than reuse of code. . and Objectory) cover the entire life cycle and stress traceability between the different phases..
the more effective it will be. The use-case model employs extends and uses relationships: y The extends relationship is used when you have one use case that is similar to another use case but does a bit more. The use case description must contain: y y y y y How and when the use case begins and ends. Every single use case should describe one main flow of events.In the requirements analysis. It is unwise to capture . How and when concepts of the problem domain are handled. The exceptional use case extends another use case to include the additional one. The uses relationship reuses common behavior in different use cases. Abstract use cases also are the ones that have uses or extends relationships. y Use cases could be viewed as concrete or abstract. The simpler the use case. This inheritance could be used in several levels. including when the interaction occurs and what is exchanged. easy to read but with a clear flow of events to follow (this is a recommended style) Formal style using pseudo code.Use Cases Use cases are scenarios for understanding system requirements. Text. Exceptions to the flow of events. The use-case model captures the goal of the user and the responsibility of the system to its users . As you can see. A use case is an interaction between users and a system. it extends functionality of the original use case (like a subclass). An abstract use case is not complete and has no actors that initiate it but is used by another use case. the use cases are described as one of the following : y y y Nonformal text with no clear flow of events. An exceptional or additional flow of events could be added. In essence. How and when the use case will need data stored in the system or will store data in the system. Fig: Some uses of a library. The interaction between the use case and its actors. these are external views of the library system from an actor such as a member.
The objects of the "real" world are mapped into the domain object model. y Test model. but Jacobson also employs a number of unique symbols listed below. The implementation model represents the implementation of the system. Send Message Receive Message Return Message Send Signal Receive Signal I. y Domain object model. Objectory is built around several different models: y Use case-model. The system development method based on OOSE. Interaction diagrams are similar to UML's sequence diagrams.all of the details right at the start. and reports. and testing. The use-case model defines the outside (actors) and inside (use case) of the system's behavior. State transition diagrams are like UML statechart diagrams. It is an approach to objectoriented analysis and design that centers on understanding the ways in which a system actually is used. validation. y Analysis object model. The analysis object model presents how the source code (implementation) should be carried out and written. the method produces systems that are both more usable and more robust. specifications. Perform Task Decision Label Object-Oriented Software Engineering: Objectory Object-oriented software engineering (OOSE). adapting more easily to changing usage.'s Objectory has been developed and applied to numerous application areas and embodied in the CASE tool systems. you can do that later. State transition diagrams are like UML state chart diagrams. is a disciplined process for the industrialized development of software. The test model constitutes the test plans. . By organizing the analysis and design models around sequences of user interaction and actual usage scenarios. stresses that use cases are involved in several phases of the development including analysis. Jacobson's Design Model Jacobson's design model shows how the system behaves. The development process. Objectory. real-time systems. design. y Implementation model. also called Objectory. The use-case scenario begins with a user of the system initiating a sequence of interrelated events. Interaction diagrams are similar to UML's sequence diagrams. based on a use-case driven design. is a method of object-oriented development with the specific aim to fit the development of large. Jacobson et al. called use-case driven development. There are two types of diagrams under this model: interaction diagrams and state transition diagrams.
It may be possible to identify the implementation environment concurrently with analysis. and system. Jacobson does not dwell on the development of the problem-domain object model. constraints due to the programming language. Object-Oriented Business Engineering Object-oriented business engineering (OOBE) is object modeling at the enterprise level. and incorporation of graphical user interface tools. . available component libraries. The levels include unit testing. the requirements model. A process is created when the first development project starts and is terminated when the developed system is taken out of service. Analysis phase: The analysis phase defines the system to be built in terms of the problem-domain object model. suggest that prototyping with a tool might be useful during this phase to help specify user interfaces. The analysis objects are translated into design objects that fit the current implementation environment. Testing phase: Finally. since the description of the system will be independent of hardware and software requirements. providing traceability throughout the software engineering processes.testing. Design and implementation phases: The implementation environment must be identified for the design model. II.Fig: The use ± case model is considered in every model and phase. integration testing. The analysis process should not take into account the actual implementation environment. distribution of process. Use cases again are the central vehicle for modeling. Jacobson et al. This includes factors such as Database Management System (DBMS). and the analysis model. Jacobson describes several testing levels and techniques. The analysis process is iterative but the requirements and analysis models should be stable before moving on to subsequent models. The maintenance of each model is specified in its associated process. This reduces complexity and promotes maintainability over the life of the system. this model should be developed just enough to form a base of understanding for the requirements model.
They have mainly adopted four goals from their methodologies: y y y y Represent the complete system (Business to Business B2B) using object oriented concepts. The UML is also evolved by the same authors to introduce consistent object oriented model notation. and guidelines along with the Object Management Group's (OMG) unified modeling language (UML). which has several static and dynamic models applied to phases of software development. prototyping and continuous testing UA methodologies and technology Unified Modeling Language (UML) Layered Architecture OO Repository for OO System development Patterns and Frameworks Component Based Development (CBD) . The UA processes. which was not specified in the OMG's UML. methodologies and technology UA Process Use Case driven development Object oriented analysis (OOA) Object oriented Design (OOD) Incremental development. which is usable by both human and machine. Rumbaugh. The task of UA is to specify the software development methodology. It combines their best practices. and Jacobson.The Unified Approach The unified approach (UA) is based on methodologies of Booch. instead of only the software .portion Establish explicit coupling between concepts and executable code Arrive scaling factors for complex and critical systems Provide versatile modeling language. processes. The UA core concept is based on Jacobson's Use Case.
The steps followed in OOA are: OOA Step 1: Identify the actors: Who is the user of the system? OOA Step 2: A simple business process model using UML activity diagram has to be developed.The Unified Approach (with its processes and components) OOA The goal of OOA is to understand the problem domain and the systems responsibilities by understanding how the users will use the system. OOA Step 3: Develop the Use Case: List the works carried out by users in the system Provide comprehensive documentation of the system under study. OOA Step 4: Develop interaction Diagrams to identify classes Determine the sequence of action and Develop sequence and collaboration diagrams OOA Step 5: Develop static UML classes diagram (i) Identify classes (ii) Identify relationships (iii)Identify attributes (iv) Identify methods OOA Step 6: Iterate and refine if needed. repeat the preceding steps .
It consists of Designing classes. (c) Simplify classes and their relationships by eliminating redundant classes and classes with a single method. structures and protocols (b) Refine and complete the UML Class Diagram by adding details. Selecting one and eliminating other simplify these classes. . (i) Refine attributes (ii) Design methods and protocols by utilizing a UML activity diagram to represent the method's algorithm (iii) Refine associations between classes (if required) (iv) Refine class hierarchy and design with inheritance (if required) (c) Iterate and refine again OOD Step 2: Design Access Layer classes (a) Create access layer classes for every classes identified and created in Business layer (simply mirror the class) (b) Identify access layer class relationships. design access and user interface view layer and develop user satisfaction and usability test. identify view layer objects (b) Design the micro level user interface. methods. OOD Step 3: Design View Layer classes (a) Design the macro level user interfaces. methods. Iterative Development and Continuous Testing The iteration process is carried out until the users are satisfied with the system.OOD OOD of UA combines Jacobson's interaction diagrams. (ii) Method Classes: Classes that consist of only one or two methods are called as method classes. attributes. The elaborated OOD steps are: OOD Step 1: Design Business Layer classes (a) Apply design axioms to design classes. methods and associations. This step consists of Refine attributes. (d) Iterate and refine them again. They can be eliminated or combined with existing classes if possible. Since testing often uncovers weaknesses of the design or any other additional information that is used. associations. (i) Redundant classes: Classes that perform similar request and activities are called as redundant classes. which includes these activities: (i) Design the view layer objects by applying the design axioms and Corollaries (ii) Build a prototype of the view layer interface (c) Do the Tests for usability and user satisfaction (d) Iterate and refine OOD Step 4: Iterate and refine the whole design. Booch's Object Diagrams and Rumbaugh's Domain model. visibility. association and class hierarchy. Re-apply the design axioms and if needed repeat the preceding steps. their attributes. the OOAD process is re-prototyped or re-tested. cardinality.
The Layered Architecture The layered approach of UA is followed in client-server application development environment that tend to lean towards n-tier architecture. (b) View Layer The View / User Interface layer consists of objects with which the user interacts as well as the objects required to manage or to control the interface. . The view layer objects are also identified during the design phase of OOSD. They are designed to be independent of any particular interface. Jacobson. business layer (business logic and queries) and View layer (user interface). Also.The business layer acts as an intermediate between Access and View layer communication. The responsibilities of the business layer are: (i) Displaying Details: The view layer request is sent to access layer and response is displayed in view layer through the business objects in. UML is dealt in detail in the remaining chapters. and user interfaces in an easily accessible manner with a completely available and easily utilized format. There are three layers (Figure 4. Since the design and development of applications are stored in common repository. Rumbaugh and with contribution from many others. (a) Business Layer The Business Layer includes all the objects that represent the business (both data and behavior). The Business layer objects are identified during the design phase of Object Oriented Software Development (OOSD). assembling already existing components are made easy. the past experience will increase the quality of the product and reduce the cost and development time in future projects. The UA uses the UML to describe and model the analysis and design phases of system development. methods or other characteristics. frameworks. Business objects do not require special knowledge of how they are being displayed and by whom. This layer typically is responsible for two major aspects of the application. Business objects need not have special knowledge of "where they come from".Modeling based on UML The Unified Modeling language was developed by the joint efforts of the authors Booch. (ii) Data access Details: The initiated query is sent as business objects to access the required data.business layer. Hence the details of how to display an object should exist in the interface layer of the object displaying it. patterns. It is integrated with several diagrams from the existing models to provide complete solution Of the system.4) in layered approach: access layer (database storage and retrieval). It is relatively easy to search the repository for classes based on their attributes. The business objects are modeled during the OOA. UA Repository Repository allows the maximum reuse of previous experience and previously defined objects. It does not matter to the business model whether the data are stored and retrieved via SQL or file I/O.
It requires just the knowledge of which message to send to which business object. (ii) Translate results: The access layer must also be able to translate the data retrieved back into the appropriate business objects and pass those objects back into the business layer. A. This layer must provide the information to the user in the form of list boxes. It does not require the business logic. Christerson. Pearson Education.Sriram. (c) Access Layer The Access Layer contains objects of that know how to communicate with the place where the data actually reside (database). H. REFERENCES y y y y ³ Object ± Oriented Analysis and Design With Applications´ .(i) Responding to user interaction: The user interface layer objects must be designed to interpret the actions of the user and translate the actions by the user. according to the requirement.Srimathi. There are two major responsibilities for the access layer. Scitech Publications. Second Edition ±Grady Booch ³ Object ± Oriented Software Engineering A Use case driven approach´ . such as clicking on a button or selecting from a menu. Jonsson. Second Edition ±H. Overgaard ³ Object ± Oriented Analysis and Design Using UML´ . Tata McGrawHill-Ali Bahrami .Krishnamoorthy ³ Object ± Oriented Systems Development using the unified modeling language´ . Pearson Education ± Ivar Jacobson. into an appropriate response. (ii) Displaying business objects: This layer must paint the best possible picture of the business objects for the user. entry fields and graphs. They are: (i) Translate request: The access layer must be able to translate any data related requests from the business layer into the appropriate protocol for enabling data access. text boxes.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.