zOBJECT ORIENTED ANALYSIS AND DESIGN UNIT 1
INTRODUCTION
Introduction to object oriented systems, UP phases: Inception, Elaboration, Construction and Transition, Object-oriented metrics, OO Life Cycle DevelopmentINTRODUCTION TO OBJECT ORIENTED SYSTEMS
Object Orientation is a term used to describe the object oriented (OO) method of building software. In an OO approach, the data is treated as the most important element and it cannot flow freely around the system. Restrictions are placed on the number of units that can manipulate the data. This approach binds the data and the methods that will manipulate the data closely and prevents the data from being inadvertently modified. What is OOAD? Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and runtime deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.Object-oriented systems An object-oriented system is composed of objects. The behavior of the system results from the collaboration of those objects. Collaboration between objects involves those sending messages to each other. Sending a message differs from calling a function in that when a target object receives a message, it itself decides what function to carry out to service that message. The same message may be implemented by many different functions, the one selected depending on the state of the target object. The implementation of "message sending" varies depending on the architecture of the system being modeled, and the location of the objects being communicated with.
Object-oriented analysis Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed. Analysis models do not consider any implementation constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built. Implementation constraints are dealt during object-oriented design (OOD). Analysis is done before the Design. The sources for the analysis can be a written requirements statement, a formal vision document, and interviews with stakeholders or other interested parties. A system may be divided into multiple domains, representing different business, technological, or other areas of interest, each of which are analyzed separately. The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one or more UML class diagrams, and a number of interaction diagrams. It may also include some kind of user interface mock-up. The purpose of object oriented analysis is to develop a model that describes computer software as it works to satisfy a set of customer defined requirements.
Object-oriented design
Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take account of the constraints imposed by the chosen architecture and any nonfunctional technological or environmental constraints, such as transaction throughput, response time, run-time platform, development environment, or programming language. The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model of the solution domain, a detailed description of how the system is to be built.UP (UNIFIED PROCESS) PHASES
The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best- known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP).
Overview
The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The Rational Unified Process is, similarly, a customizable framework. As a result it is often impossible to say whether a refinement of the process was derived from UP or from RUP, and so the names tend to be used interchangeably. The name Unified Process as opposed to Rational Unified Process is generally used to describe the generic process, including those elements which are common to most refinements. The Unified Process name is also used to avoid potential issues of trademark infringement since Rational Unified Process and RUP are trademarks of IBM. Unified Process Characteristics: Iterative and Incremental the Unified Process is an iterative and incremental development process. The Elaboration, Construction and Transition phases are divided into a series of time boxed iterations. (The Inception phase may also be divided into iterations for a large project.) Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release. Although most iterations will include work in most of the process disciplines (e.g. Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.
Use Case Driven: In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of usecases or scenarios from requirements all the way through implementation, test and deployment.
Architecture Centric:
The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views. One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase.Risk Focused: The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.
Project Lifecycle:The Unified Process divides the project into four phases:
Inception
Elaboration
Construction
Transition
Inception Phase:
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process.
The following are typical goals for the Inception phase.
Establish a justification or business case for the project
Establish the project scope and boundary conditions
Outline the use cases and key requirements that will drive the design tradeoffs
Outline one or more candidate architectures
Identify risks
Prepare a preliminary project schedule and cost estimate
The Lifecycle Objective Milestone marks the end of the Inception phase. Elaboration Phase: During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams). The architecture is validated primarily through the implementation of an Executable Architecture Baseline. This is a partial implementation of the system which includes the core, most architecturally significant, components. It is built in a series of small, time boxed iterations. By the end of the Elaboration phase the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability and cost. The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the Construction phase. At this point the plan should be accurate and credible; since it should be based on the Elaboration phase experience and since significant risk factors should have been addressed during the Elaboration phase. The Lifecycle Architecture Milestone marks the end of the Elaboration phase.Construction Phase: Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, time boxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one become the start of a new iteration. Common UML (Unified Modeling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and interaction Overview diagrams. The Initial Operational Capability Milestone marks the end of the Construction phase.Transition Phase: The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations. The Transition phase also includes system conversions and user training. The Product Release Milestone marks the end of the Transition phase.
OBJECT-ORIENTED METRICS
Increasingly, object-oriented measurements are being used to evaluate and predict the quality of software a growing body of empirical results supports the theoretical validity of these metrics.
The validation of these metrics requires convincingly demonstrating that the metric measures what it purports to measure (for example, a coupling metric really measures coupling) and the metric is associated with an important external metric, such as reliability, maintainability and fault-proneness.
Metrics for Analysis
When code is analyzed for object-oriented metrics, often two suites of metrics are used, the Chidamber-Kemerer (CK) and MOOD suites. In this section, we enumerate and explain the specific measures that can be computed using this tool.
Coupling
"Coupling is a measure of interdependence of two objects For example, objects A and B are coupled if a method of object A calls a method or accesses a variable in object B. Classes are coupled when methods declared in one class use methods or attributes of the other classes.
Cohesion
Cohesion refers to how closely the operations in a class are related to each other. Cohesion of a class is the degree to which the local methods are related to the local instance variables in the class. The CK metrics suite examines the Lack of Cohesion (LOCOM), which is the number of disjoint/non-intersection sets of local methods.There are at least two different ways of measuring cohesion:
1. Calculate for each data field in a class what percentage of the methods use that data field. Average the percentages then subtract from 100%. Lower percentages mean greater cohesion of data and methods in the class.
2. Methods are more similar if they operate on the same attributes. Count the number of disjoint sets produced from the intersection of the sets of attributes used by the methods.
High cohesion indicates good class subdivision. Lack of cohesion or low cohesion increases complexity, thereby increasing the likelihood of errors during the development process. Classes with low cohesion could probably be subdivided into two or more subclasses with increased cohesion. This metric evaluates the design implementation as well as reusability.
Encapsulation
Information hiding is a way of designing routines such that only subsets of the modules properties, its public interface, are known to users of the module. Information hiding gives rise to encapsulation in object-oriented languages. "Encapsulation means that all that is seen of an object is its interface, namely the operations we can perform on the object.Information hiding is a theoretical technique that indisputably proven its value in practice.
Attribute Hiding Factor (AHF)
The Attribute Hiding Factor measures the invisibilities of attributes in classes. The invisibility of an attribute is the percentage of the total classes from which the attribute is not visible. An attribute is called visible if it can be accessed by another class or object. Attributes should be "hidden" within a class
Method Hiding Factor (MHF)
The Method Hiding Factor measures the invisibilities of methods in classes. The invisibility of a method is the percentage of the total classes from which the method is not visible. The Method Hiding Factor is a fraction where the numerator is the sum of the invisibilities of all methods defined in all classes. The denominator is the total number of methods defined in the project.Inheritance
Inheritance decreases complexity by reducing the number of operations and operators, but this abstraction of objects can make maintenance and design difficult. The two metrics used to measure the amount of inheritance are the depth and breadth of the inheritance hierarchy.
Depth of Inheritance Tree (DIT)
The depth of a class within the inheritance hierarchy is defined as the maximum length from the class node to the root/parent of the class hierarchy tree and is measured by the number of ancestor classes. In cases involving multiple inheritances, the DIT is the maximum length from the node to the root of the tree.Number of Children (NOC) This metric is the number of direct descendants (subclasses) for each class. Classes with large number of children are considered to be difficult to modify and usually require more testing because of the effects on changes on all the children. They are also considered more complex and fault-prone because a class with numerous children may have to provide services in a larger number of contexts and therefore must be more flexible.Complexity
Weighted Methods/Class (WMC)
WCM measures the complexity of an individual class. A class with more member functions than its peers is considered to be more complex and therefore more error prone. The larger the number of methods in a class, the greater the potential impact on children since children will inherit all the methods defined in a class. Classes with large numbers of methods are likely to be more application specific, limiting the possibility of reuse. This reasoning indicates that a smaller number of methods is good for usability and reusability.
OO LIFE CYCLE DEVELOPMENT
System development can be viewed as a process. The development itself, in essence, is a process of change, refinement, transformation, or addition to existing product. The process can be divided into small, interacting phases sub processes. Each sub process must have the following:
1. A description in terms of how it works
2. Specification of the input required for the process
3. 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 the input of the subsequent transformation. Analysis
Design
Implementation
Analysis
In academic environments software often seems to grow, without a clear plan or explicit intention of fulfilling some need or purpose, except perhaps as a vehicle for research. In contrast, industrial and business software projects are usually undertaken to meet some explicit goal or to satisfy some need. One of the main problems in such situations, from the point of view of the developers of the software, is to extract the needs from the future users of the system and later to negotiate the solutions proposed by the team. The problem is primarily a problem of communication, of bridging the gap between two worlds, the world of domain expertise on the one hand and that of expertise in the craft of software development on the other.Analysis methods
Functional Decomposition = Functions + Interfaces
Data Flow Approach = Data Flow + Bubbles
Information Modeling = Entities + Attributes + Relationships
Object-Oriented = Objects + Inheritance + Message passing
Design
In an object-oriented approach, the distinction between analysis and design is primarily one of emphasis; emphasis on modeling the reality of the problem domain versus emphasis on providing an architectural model of a system that lends itself to implementation. One of the attractive features of such an approach is the opportunity of a seamless transition between the respective phases of the software product in development. The classical waterfall model can no longer be considered as appropriate for such an approach. An alternative model, the fountain model, is proposed by Hend. This model allows for a more autonomous development of software components, within the constraints of a unifying framework. The end goal of such a development process may be viewed as a repository of reusable components.
Implementation
In principle, the phase of implementation follows on from the design phase. In practice, however, the products of design may often only be regarded as providing a post hoc justification of the actual system. The most important distinction between design and implementation is hence the level of abstraction at which the structure of the system is described. Design is meant to clarify the conceptual structure of a system, whereas the implementation must include all the details needed for the system to run. UNIT II
MODELINGBooch Methodology-Unified Modeling Language Use case Diagram - Class Diagram - Interactive Diagram- Package Diagram - Collaboration Diagram - State Diagram - Activity Diagram
BOOCH METHODOLOGY
The Booch software engineering methodology provides an object-oriented development in the analysis and design phases. The analysis phase is split into two steps. The first step is to establish the requirements from the customer perspective. This analysis step generates a high-level description of the system's function and structure. The second step is a domain analysis. The domain analysis is accomplished by defining object classes; their attributes, inheritance, and methods. State diagrams for the objects are then established. The analysis phase is completed with a validation step.
Booch's methodology has its primary strength in the object system design. Grady Booch has included in his methodology a requirements analysis that is similar to a traditional requirements analysis, as well as a domain analysis phase. Booch's object system design method has four parts, the logical structure design where the class hierarchies are defined, and the physical structure diagram where the object methods are described. In addition, Booch defines the dynamics of classes in a fashion very similar to the Rumbaugh method, as well as an analysis of the dynamics of object instances, where he describes how an object may change state.Booch suggests the following order of events for the formalization of the strategy:
Identify the classes and objects at a given level of abstraction. Identify the semantics of these classes and objects. Identify the relationships among these classes and objects. Implement these classes and objects.Identifying the classes and objects involves finding key abstractions in the problem space and important mechanisms that offer the dynamic behavior over several such objects. These key abstractions are found by studying the terminology of the problem domain.
Identifying the semantics involves establishing the meanings of the classes and objects identified in the previous stage. The developer should view the objects from the outside, define the object protocol and investigate how each object may be used by other objects.
Identifying relationships extends the previous work to include the relationships between classes and objects and to identify how these interact with each other. Associations such as inheritance, instantiation and uses between the classes are defined, as are the static and dynamic semantics of the mechanisms between the objects. The visibility between classes and objects is also decided upon
Implementing classes and objects involves delving into the classes and objects and determining how to implement them in the chosen programming language. This is also the step where components are used, and the classes and objects are structured into modules.
One of the major strength's of Booch's method is the rich notation available. There are diagrammatic notations for producing:
class diagrams (class structure - static view) object diagrams (object structure - static view) state transition diagrams (class structure - dynamic view) timing diagrams (object structure - dynamic view) module diagrams (module architecture) process diagrams (process architecture)The notations for class and object modeling use annotations or variant symbols (e.g. different kinds of arrow) to convey detailed information. Booch suggests that a subset of the notations can be used in the earlier stages of design, with the detail being filled in later. There is also a textual form for each notation, consisting of templates for documenting each major construct.The Booch method includes six types of diagrams such as class diagrams, object diagrams, state transition diagrams, module diagrams, process diagrams and interaction diagrams.
UNIFIED MODELING LANGUAGEUnified Modeling Language (UML) is the set of notations, models and diagrams used when developing object-oriented (OO) systems.
UML is the industry standard OO visual modeling language. The latest version is UML 1.4 and was formed from the coming together of three leading software methodologists; Booch,
Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of software-intensive systems.
The Unified Modeling Language is commonly used to visualize and construct systems which are software intensive. Because software has become much more complex in recent years, developers are finding it more challenging to build complex applications within short time periods. Even when they do, these software applications are often filled with bugs, and it can take programmers weeks to find and fix them. This is time that has been wasted, since an approach could have been used which would have reduced the number of bugs before the application was completed. However, it should be emphasized that UML is not limited simply modeling software. It can also be used to build models for system engineering, business processes, and organization structures. A special language called Systems Modeling Language was designed to handle systems which were defined within UML 2.0. The Unified Modeling Language is important for a number of reasons. First, it has been used as a catalyst for the advancement of technologies which are model driven, and some of these include Model Driven Development and Model Driven Architecture.Because an emphasis has been placed on the importance of graphics notation, UML is proficient in meeting this demand, and it can be used to represent behaviors, classes, and aggregation. While software developers were forced to deal with more rudimentary issues in the past, languages like UML have now allowed them to focus on the structure and design of their software programs. It should also be noted that UML models can be transformed into various other representations, often without a great deal of effort. One example of this is the ability to transform UML models into Java representations.
USE CASE DIAGRAM
A use case diagram is a graphic depiction of the interactions among the elements of a system.A use case is a methodology used in system analysis to identify, clarify, and organize system requirements. Use case diagrams are employed in UML (Unified Modeling Language), a standard notation for the modeling of real-world objects and systems.
Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system.
UML 2 use case diagrams overview the usage requirements for a system. They are useful for presentations to management and/or project stakeholders, but for actual development you will find that use cases provide significantly more value because they describe "the meat" of the actual requirements. Figure 1 provides an example of a UML 2 use case diagram.
Use case diagrams depict:
Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line.
System boundary boxes (optional).. System boundary boxes are rarely used, although on occasion I have used them to identify which use cases will be delivered in each major release of a system. Packages (optional). Packages are UML constructs that enable you to organize model elements (such as use cases) into groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including both use case diagrams and class diagrams. Use case diagrams are drawn to capture the functional requirements of a system. So after identifying the above items we have to follow the following guidelines to draw an efficient use case diagram.
The name of a use case is very important. So the name should be chosen in such a way so that it can identify the functionalities performed. Give a suitable name for actors. Show relationships and dependencies clearly in the diagram. Do not try to include all types of relationships. Because the main purpose of the diagram is to identify requirements. Use note when ever required to clarify some important points.
A use case diagram looks something like a flowchart. Intuitive symbols represent the system elements. Here's a simple example:
CLASS DIAGRAM
Class diagram in the unified Modelling Language is a static structure diagram that describes the structure of a system by shoeing all these in the system, their attributes, and the relationships between the classes.
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages and objects.
Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation.1 These perspectives become evident as the diagram is created and help solidify the design.
This example is only meant as an introduction to the UML and class diagrams. If you would like to learn more see the Resources page for more detailed resources on UML.
Classes are composed of three things:
1. name,
2. attributes, and
3. operations.
Below is an example of a class.
Class diagrams also display relationships such as containment, inheritance, associations and others.
2 Below is an example of an associative relationship:
The association relationship is the most common relationship in a class diagram. The association shows the relationship between instances of classes.
For example, the class Order is associated with the class Customer. The multiplicity of the association denotes the number of objects that can participate in then relationship.1 For example, an Order object can be associated to only one customer, but a customer can be associated to many orders. Another common relationship in class diagrams is a generalization. A generalization is used when two classes are similar, but have some differences.
Look at the generalization below:
In this example the classes Corporate Customer and Personal Customer have some similarities such as name and address, but each class has some of its own attributes and operations.
The class Customer is a general form of both the Corporate Customer and Personal Customer classes.1 This allows the designers to just use the Customer class for modules and do not require in-depth representation of each type of customer.
When to Use: Class Diagrams Class diagrams are used in nearly all Object Oriented software designs. Use them to describe the Classes of the system and their relationships to each other.
How to Draw: Class Diagrams Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and useful diagrams a person would have to study UML and Object Oriented principles for a long time.
Therefore, this page will give a very high level overview of the process. To find list of where to find more information see the Resources page.
Before drawing a class diagram consider the three different perspectives of the system the diagram will present; conceptual, specification, and implementation. Try not to focus on one perspective and try see how they all work together.
When designing classes consider what attributes and operations it will have. Then try to determine how instances of the classes will interact with each other.
These are the very first steps of many in developing a class diagram. However, using just these basic techniques one can develop a complete view of the software system.
The Relationship in a class diagram
1. Instance level Relationship
External link
Association
Aggregation
Composition
2. Class level Relationship
Generalization
Realization
Dependency
MultiplicityINTERACTIVE DIADRAM
From the name Interaction it is clear that the diagram is used to describe some type of interactions among the different elements in the model. So this interaction is a part of dynamic behaviour of the system.
This interactive behaviour is represented in UML by two diagrams known as Sequence diagram and Collaboration diagram. The basic purposes of both the diagrams are similar. Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the structural organization of the objects that send and receive messages.
Purpose: The purposes of interaction diagrams are to visualize the interactive behaviour of the system. Now visualizing interaction is a difficult task. So the solution is to use different types of models to capture the different aspects of the interaction. That is why sequence and collaboration diagrams are used to capture dynamic nature but from a different angle. So the purposes of interaction diagram can be describes as:
To capture dynamic behaviour of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.
How to draw Component Diagram? The purpose of interaction diagrams is to capture the dynamic aspect of a system. So to capture the dynamic aspect we need to understand what a dynamic aspect is and how it is visualized. Dynamic aspect can be defined as the snap shot of the running system at a particular moment. We have two types of interaction diagrams in UML.
One is sequence diagram-The sequence diagram captures the time sequence of message flow from one object to another and
The collaboration diagram -describes the organization of objects in a system taking part in the message flow.
So the following things are to identified clearly before drawing the interaction diagram:
Objects taking part in the interaction.
Message flows among the objects.
The sequence in which the messages are flowing.
Object organization.
Following are two interaction diagrams modelling order management system. The first diagram is a sequence diagram and the second is a collaboration diagram.
The Sequence Diagram: The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder). The following diagram has shown the message sequence for SpecialOrder object and the same can be used in case of NormalOrder object. Now it is important to understand the time sequence of message flows. The message flow is nothing but a method call of an object. The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a method of SpecialOrder object and the last call is Dispatch () which is a method of SpecialOrder object. So here the diagram is mainly describing the method calls from one object to another and this is also the actual scenario when the system is running.
Collaboration Diagram:
The second interaction diagram is collaboration diagram. It shows the object organization as shown below. Here in collaboration diagram the method call sequence is indicated by some numbering technique as shown below.
The number indicates how the methods are called one after another. We have taken the same order management system to describe the collaboration diagram. The method calls are similar to that of a sequence diagram.
But the difference is that the sequence diagram does not describe the object organization where as the collaboration diagram shows the object organization.
Now to choose between these two diagrams the main emphasis is given on the type of requirement. If the time sequence is important then sequence diagram is used and if organization is required then collaboration diagram is used.
Where to use Interaction Diagrams?
Interaction diagrams are used to describe dynamic nature of a system. To understand the practical application we need to understand the basic nature of sequence and collaboration diagram.
The main purposes of both the diagrams are similar as they are used to capture the dynamic behaviour of a system. But the specific purposes are more important to clarify and understood.
Sequence diagrams are used to capture the order of messages flowing from one object to another. And the collaboration diagrams are used to describe the structural organizations of the objects taking part in the interaction.
A single diagram is not sufficient to describe the dynamic aspect of an entire system so a set of diagrams are used to capture is as a whole.
The interaction diagrams are used when we want to understand the message flow and the structural organization.
Now message flow means the sequence of control flow from one object to another and structural organization means the visual organization of the elements in a system. In a brief the following are the usages of interaction diagrams:
To model flow of control by time sequence.
To model flow of control by structural organizations.
For forward engineering.
For reverse engineering.
PACKAGE DIAGRAM:
A package diagram is a UML diagram composed only of packages and the dependencies between them. A package is a UML construct that enables you to organize model elements, such as use cases or classes, into groups.
Packages are depicted as file folders and can be applied on any UML diagram. Create a package diagram to:
Depict a high-level overview of your requirements (overviewing a collection of UML Use Case diagrams)
Depict a high-level overview of your architecture/design (overviewing a collection of UML Class diagrams).
To logically modularize a complex diagram.
To organize Java source code.
There are guidelines for:
1. Class Package Diagrams
2. Use Case Package Diagrams
3. Packages
1. Create UML Component Diagrams to Physically Organize Your Design.
2. Place Sub packages Below Parent Packages.
3. Vertically Layer Class Package Diagrams.
4. Create Class Package Diagrams to Logically Organize Your Design. Error! Reference source not found. Depicts a UML Class diagram organized into packages. In addition to the package guidelines presented below, apply the following heuristics to organize UML Class diagrams into package diagrams: Place the classes of a framework in the same package. Classes in the same inheritance hierarchy typically belong in the same package. Classes related to one another via aggregation or composition often belongs in the same package. Classes that collaborate with each other a lot, information that is reflected by your UML Sequence diagrams and UML Collaboration diagrams, often belong in the same package.
Use cases are often a primary requirement artifact in object-oriented development methodologies, this is particularly true of instantiations of the Unified Process, and for larger projects package diagrams are often created to organize these usage requirements.
Packages
A package in the Unified Modelling Language is used to group elements, and to provide a namespace for the grouped elements.The advice presented in this section is applicable to the application of packages on any UML diagram, not just package diagrams.
1. Give Packages Simple, Descriptive Names
2. Apply Packages to Simplify Diagrams
3. Packages Should be Cohesive
4. Indicate Architectural Layers With Stereotypes on Packages
5. Avoid Cyclic Dependencies Between Packages
6. Package Dependencies Should Reflect Internal Relationships
Use Case Package Diagrams
Use cases are often a primary requirement artefact in object-oriented development methodologies, this is particularly true of instantiations of the Unified Process, and for larger projects package diagrams are often created to organize these usage requirements.
1. Create Use Case Package Diagrams to Organize Your Requirements
2. Include Actors on Use Case Package Diagrams
3. Horizontally Arrange Use Case Package Diagrams.
There are two special types of dependencies between packages,
Package import
Package merge
Package import:
It is a relationship between an importing namespace and a package, indicating that the importing namespace adds the names of the members of the packages to its own namespace. This is the default relationship.
Package merges:
It is directed relationship between two packages, which indicates that the content of the two packages are to be combined.
It is very similar to Generalization in the sense that the source element conceptually adds the characterised of the target element to its own characterized resulting in an element that combines the characterises of both.COLLABORATION DIAGRAM
A collaboration diagram, also called a communication diagram or interaction diagram, is an illustration of the relationships and interactions amongsoftwareobjects in the Unified Modeling Language (UML). The concept is more than a decade old although it has been refined as modeling paradigms have evolved.Collaboration diagrams show the message flow between objects in an OO application, and also imply the basic associations (relationships) between classes. Collaboration diagrams are often used to:
Provide a birds-eye view of a collection of collaborating objects, particularly within a real-time environment.
Allocate functionality to classes by exploring the behavioral aspects of a system.
Model the logic of the implementation of a complex operation, particularly one that interacts with a large number of other objects.
Explore the roles that objects take within a system, as well as the different relationships they are involved with when in those roles.
There are guidelines for:
1. General issues2. Messages3. Links1. General
Fig1. An Instance-Level UML Collaboration diagram.1. Use Instance-Level Diagrams To Explore Object Design Issues. Instance-level UML Collaboration diagrams, such as the one shown inFigure 1, depict interactions between objects (instances). Instance-level diagrams are typically created to explore the internal design of object-oriented software.
2. Use Specification-Level Diagrams to Explore Roles. Specification-level UML Collaboration diagrams, such as the one shown inFigure 3, are used to analyze and explore the roles taken by domain classes within a system.
3. Collaboration Diagrams Do Not Model Process Flow.
4. When Sequence Is Important Use a Sequence Diagram.
5. Apply Sequence Diagram Guidelines To Instance-Level Collaboration Diagrams. Because UML Collaboration diagrams depict an alternate view of the same information as UML Sequence diagrams much of the same style advice applies. The following lists of guidelines, originally presented for UML Sequence diagrams, are applicable to collaboration diagrams:
Name Objects When Your Reference Them In Messages
Name Objects When Several of the Same Type Exist
Apply Textual Stereotypes Consistently
Apply Visual Stereotypes Sparingly
Focus on Critical Interactions
Prefer Names Over Types for Parameters
Indicate Types as Parameter Placeholders
Do Not Model a Return Value When it is Obvious What is Being Returned
Model a Return Value Only When You Need to Refer to it Elsewhere
Model Return Values as Part of a Method Invocation
Indicate Types as Return Value Placeholders
2. Messages
Figure 2presents the notation for invoking messages on UML Collaboration diagrams. For example inFigure 1the message1.2: orderTotal := calculateTotal()indicates a sequence number of 1.2, there is no loop occuring, a return value oforderTotaland an invoked method namedcalculateTotal().Fig 2.A UML Collaboration diagram depicting concurrent message invocations.
1. Indicate a Return Value Only When It Isn't Clear
2. Indicate Parameters Only When They Aren't Clear
3. Depict anArrow For Each Message
4. Consolidate Getter Invocations. When you have several getters invoked in a row a good short cut is to model a single message such asgetInfo()inFigure 1to act as a placeholder.
5. IndicateConcurrent ThreadsWith Letters.Links
The lines between the classifiers depicted on a UML Collaboration diagram represent instances of the relationships - including associations, aggregations, compositions, and dependencies - between classifiers.
Fig 3. A Specification-Level UML Collaboration diagram.
1. Model "Bare" Links On Instance-Level Collaboration Diagrams
2. Show Role-Pertinent Information on Specification-Level Diagrams. InFigure 3 you see that the roles taken by classes as well as the high-level multiplicities (either blank or an asterisk to represent many) are depicted.
3. Prefer Roles on Links Instead of Within Classes
4. Indicate Navigability Sparingly
5. Links Should Be Consistent Static Relationships
STATE DIAGRAM
State diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as events occur.
Each diagram usually represents objects of a single class and track the different states of its objects through the system.
When to Use: State Diagrams Use state diagrams to demonstrate the behavior of an object through many use cases of the system.
Only use state diagrams for classes where it is necessary to understand the behavior of the object through the entire system.
Not all classes will require a state diagram and state diagrams are not useful for describing the collaboration of all objects in a use case.
State diagrams are other combined with other diagrams such as interaction diagrams and activity diagrams.
How to Draw: State Diagrams State diagrams have very few elements. The basic elements are rounded boxes representing the state of the object and arrows indicting the transition to the next state.
The activity section of the state symbol depicts what activities the object will be doing while it is in that state.
All state diagrams being with an initial state of the object. This is the state of the object when it is created.
After the initial state the object begins changing states. Conditions based on the activities can determine what the next state the object transitions to.
Below is an example of a state diagram might look like for an Order object. When the object enters the Checking state it performs the activity "check items."
After the activity is completed the object transitions to the next state based on the conditions [all items available] or [an item is not available].
If an item is not available the order is canceled. If all items are available then the order is dispatched. When the object transitions to the Dispatching state the activity "initiate delivery" is performed.
After this activity is complete the object transitions again to the Delivered state.
State diagrams can also show a super-state for the object. A super-state is used when many transitions lead to the a certain state.
Instead of showing all of the transitions from each state to the redundant state a super-state can be used to show that all of the states inside of the super-state can transition to the redundant state.
This helps make the state diagram easier to read. The diagram below shows a super-state. Both the Checking and Dispatching states can transition into the Canceled state, so a transition is shown from a super-state named Active to the state Cancel.
By contrast, the state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching state to the Delivered state.
Thestate diagramin theUnified Modeling Languageis essentially aHarel statechartwith standardized notation[1],[2]which can describe many systems, from computer programs to business processes. In UML 2 the name has been changed toState Machine Diagram. The following are the basic notational elements that can be used to make up a diagram:
Filled circle, pointing to the initial state
Hollow circle containing a smaller filled circle, indicating the final state (if any)
Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicated
Arrow, denoting transition. The name of the event (if any) causing this transition labels the arrow body. Aguardexpression may be added before a "/" and enclosed in square-brackets (eventName[guardExpression]), denoting that this expression must be true for the transition to take place. If an action is performed during this transition, it is added to the label following a "/" (eventName[guardExpression]/action).
Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively.
ACTIVITY DIAGRAMActivity diagramis UMLbehavior diagramwhich showsflow of controlorobject flowwith emphasis on the sequence and conditions of the flow.
The actions coordinated by activity models can be initiated because other actions finish executing, because objects and data become available, or because some events external to the flow occur.
The following nodes and edges are typically drawn onUMLactivity diagrams:activity,partition,action,object,control,activity edge.Activity
Activityis a parameterizedbehaviorrepresented as coordinated flow ofactions.
Theflow of executionis modeled as activity nodes connected by activity edges. A node can be the execution of a subordinate behavior, such as an arithmetic computation, a call to an operation, or manipulation of object contents. Activity nodes also include flow of control constructs, such as synchronization, decision, and concurrency control. Activities may form invocation hierarchies invoking other activities, ultimately resolving to individual actions. In an object-oriented model, activities are usually invoked indirectly as methods bound to operations that are directly invoked.
Activity containsactivity nodeswhich could be:
1. Action 2. Object 3. ControlActivities may containactionsof various kinds:
Occurrences of primitive functions, such as arithmetic functions. Invocations of behavior, such as activities. Communication actions, such as sending of signals. Manipulations of objects, such as reading or writing attributes or associations.
There are actions that invoke activities - either directly usingcall behavior actionor indirectly withcall operation action.
Activity could be rendered as round-cornered rectangle with activity name in the upper left corner and nodes and edges of the activity inside the border. UML 2.4 specification examples show activity name in bold.
Online Shopping activity.
Activity parameters are displayed on the border and listed below the activity name as:parameter-name:parameter-type.
Authenticate User activity with two parameters - Login Id and Password.
As abehavioractivity could have pre- and post-condition constraints. If present, these are shown with the keywords precondition and post condition, respectively.
The keyword single Execution is used for activities that execute as a single shared execution (singleton), otherwise, each invocation executes in its own space.
The round-cornered activity border may be replaced with the frame notation for diagrams. The kind of the frame in this case isactivityoractin short form. Activity parameters if any are displayed on the frame.
Authenticate User activity frame with two parameters - Login Id and Password.
The notation for classes with the keyword activity can be used to show the features of a reflective activity, to indicate it is an activity class. Association and state machine notation can also be used as necessary.
UML allows behaviors to produce tokens that areactivitiesand which can in turn be executed at the runtime.
Activity Partition
An activitypartitionisactivity groupfor actions that have some common characteristic.
Partitions often correspond toorganizational unitsorbusiness actorsin abusiness model.
Partitions provide a constrained view on the behaviors invoked in activities. Constraints could be selected according to the type of the element that the partition represents. The following constraints are normative (standard) in UML 2.4:
Classifier Instance Part Attributeand value
For example, partitions could represent specificclassifiers. In this case actions in each partition should be operations or signals targeting objects that are instances of the corresponding classifier.
A partition may represent someattributeand its subpartitions - specific values of that attribute. For example, a partition may represent the location at which a behavior is carried out, and the subpartitions would represent specific values for that attribute, such as New York.
Activitypartitionmay be shown using aswim lanenotation - with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any activity nodes, e.g. actions and edges placed between these lines are considered to be contained within the partition.
Activity partitions Customer and Order Dept as horizontal swimlanes
Activity partitions Customer and Order Dept as vertical swimlanes
Hierarchical partitioningis represented using swimlanes for subpartitions as illustrated below.
Hierarchical partitioning with subpartitions
A partition may be marked as adimensionfor its subpartitions to contain (group) those subpartitions along dimension. For example, an activity may have one dimension of partitions for location at which the contained behaviors are carried out, and another for the cost of performing them.Dimension partitionscannot be contained by any other partition.
Diagrams can also be partitioned multidimensionally, where each swim cell is an intersection of multiple partitions. The partitions within each dimension may be grouped into an enclosing activity partition with isDimension=true, whose name is the dimension name. Rather than being shown as a partition itself, however, the dimension is indicated by placing its name along side the set of partitions in the dimension.
Partition could represent anexternal entityto which the partitioning structure does not apply.External partitionsare intentional exceptions to the rules for partition structure. For example, a dimension may have partitions showing parts of astructured classifier. It can have anexternal partitionthat does not represent one of the parts, but a completely separate classifier. Inbusiness modeling, external partitions can be used to model entities outside a business.
When activities are considered to occur outside the domain of a particular model, the partition can be labeled with the keywordexternal. Whenever an activity in a swimlane is marked external, this overrides the swimlane and dimension designation.
Buyactionoccurs in externalpartitionCustomer
In the situations when swimlanes can't be used to show partitions, alternate text notation with qualified action name could be used instead. In this casepartitionname is placed in parenthesis above theactionname. A comma-delimited list of partition names means that the node is contained in more than one partition. A double colon within a partition name indicates that the partition is nested, with the larger partitions coming earlier in the name.
Buyactionoccurs in the externalpartitionCustomer
Following are the main usages of activity diagram:
Modeling work flow by using activities.
Modeling business requirements.
High level understanding of the system's functionalities.
Investigate business requirements at a later stage.
UNIT IIIANALYSISIdentifying UseCase -Use Case driven approach-Approaches for identifying classes -Attributes and methodsIDENTIFYING USECASEA Use Case captures a contract between the stakeholders of a system about its behavior. Use cases describes the systems behavior under various conditions as the system responds to requests from its users (actors) specifying how the actors goals get delivered or fail.
A use case is:
a set of scenarios that describe the behavior of the system and its users at a high level of detail with sunny-day and rainy-day scenarios being defined
A use case gathers the scenarios related to the (primary) actors goal
Actors are the people and/or computer systems that are outside the system under development (SuD)and interact with it:
Primary actor a stakeholder who requests that the system deliver a goal Supporting/secondary actor an external system against which the SuD has a goal
Scenarios are dialogs between actors and the system
A use-case is
a set of activities within a system presented from the point of view of the associated actors leading to an externally visible result a (simplified) part of a business process model
User Goal TechniqueThis is a rather obvious approach that involves talking to users and getting them to discuss their goals for the new system. The analyst would typically list all the stakeholders who are likely to interact with the system, think through their roles and identify what they would need to get their work done.
By analyzing existing systems and asking users how they would like to use the new system, the analyst can come up with an array of use cases. Use cases are thus, a combination ofexisting system functionsandnewly requested functions.
CRUD TechniqueAnother technique used for identifying use cases is CRUD, an acronym forCreate,Read or Report,Update andDelete. Here, the analyst identifies all the data elements to be processed by the system and creates use cases that create, report on, update, and delete the data items. Heres a guide to using the CRUD technique,using an online ordering website as an example:
1. Identify the data items to be handled by the system. The data items involved relate to customer, order, inventory item and shipment.2. Examine each data item and state the use cases that create the data; read or report on the data; update the data; and delete the data.
Actors An actor is an entity that is outside of the system
Actors will interact with the system:
An actor will often request the system to perform some actions on behalf of the actor An actor may also receive responses from the system
An actor plays a role in the use of the system The name given to an actor is usually the role name: for example, an actor who is a Person will usually be called a User, Operator, Administrator, or something like that Each role might be treated as a different actor in the use cases
Communication between actors and the system In each use case, a primary actor starts things off: that actor initiates an interaction with the system
The system will then respond to messages and might send messages of its own to other actors
In a use case, the primary actor is trying to achieve a specific goal: The use case consists of all the possible interactions that take place in the attempt to reach the goal there may be many scenarios in a use case - each scenario shows an alternative course that is based on the success or failure of some of the intermediate steps the goal might not be reached (because of some of the failures)
Scenarios A scenario is a little story
it is an outline of some expected sequence of events
A scenario is used to convey the fundamentals of how things work
It usually includes at least one actor
Each actor can make requests of the system or respond to system activity
Identifying actors An Automated Teller Machine (ATM) permits customers to withdraw money from their accounts, make deposits, and check their account balances. The ATM machine communicates with a computer system in the banks central office to validate passwords and account information. The ATM is serviced on a regular basis by bank employees, to collect deposit envelopes and to load in more cash and receipt paper.
Creating a simple scenario Draw a sequence diagram for one of the scenarios in the ATM system. One prominent use case in this system is customer performs an ATM transaction, and one scenario in that use case is customer withdraws money. Assume we are in the sunny-day scenario.USE CASE DRIVEN APPROACHOOA phase of UA uses actors & use cases to describe system from users perspective. Actors are external factors that interact with system; use cases are scenarios describe how actors use system Actors are external factor that interact with the system
Usecases are scenarios describe how actors use the system
The OOA process consists of following steps: - 1. Identify the actors: who is using system? In new case, who will be using the system? 2. Develop a simple business process model using UML activity diagram 3. Develop the use case: What are the users doing with the system? In case of new system, what will users be doing with the system? Use cases provide us with comprehensive documentation of system under study 4. Prepare interaction diagrams: Determine the sequence, Develop collaboration diagrams 5. Classification develop a static UML class diagram: Identify classes, Identify relationships Identify attributes Identify methods 6. Iterate and refine: if needed, repeat the preceding stepsAPPROACHES FOR IDENTIFYING CLASSES Noun phrase approach The common class patterns approach The use-case driven, sequence/collaboration modeling approach The Classes, Responsibilities, and Collaborators (CRC) approachNoun phrase approach:Nouns in the textual description are considered to be classes and verbs to be methods of the classes. All plurals are changed to singular, the nouns are listed and the list divided into relevant classes, fuzzy classes and irrelevant class.Three categories:
Relevant classes.
Fuzzy classes.
Irrelevant classes.
Identifying tentative classes.
Look for noun phrases and nouns in the use cases.
Some classes are implicit or taken from general knowledge.
All classes must make sense in the application domain.
Carefully choose and define class names.
Selecting classes from the relevant and fuzzy classes.
Redundant classes.
Adjective classes.
Attribute classes.
Irrelevant classes.
The common class patterns approach Concept class
Events class
Organization class
People class
Places class
Tangible things and devices class
The use-case driven, sequence/collaboration modeling approach 1. Create sequence/collaboration diagram 2. Identify class from the diagram 3. Identify operation from the diagram 4. Identify collaboration from the diagramThe Classes, Responsibilities, and Collaborators (CRC) approach1. Identify classes responsibilities (and identify classes)
2. Assign responsibilities
3. Identify collaboratorIDENTIFYING ATTRIBUTES AND METHODS: Identifying attributes and method is like finding classes, still a difficult activity and an iterative process.
Once again use case and other UML diagrams will be our guide for identifying attributes, methods and relationship among the classes.
Responsibilities identify problems to be solved Attributes are things an object must remember such as color, cost and manufacturer
Identifying attributes of a systems classes starts with understanding the systems responsibilities Following questions help in identifying the responsibilities of classes and deciding what data elements to keep track of: 1. What information about an object should we keep track of? 2. What services must a class provide?
Defining attributes by analyzing usecases and other UML diagrams: Attributes can be derived from scenario testing; therefore, by analyzing the usecases and sequence/collaboration, activity and state diagrams, we can begin to understand classes, responsibilities and how they must interact to perform their tasks. Main goal here is to understand want the class is responsible for knowing. Responsibilities is the key issues Using previous OOA results for analysis patterns can be extremely useful in finding out what attributes can be reused directly and what lessons can be learned for identifying attributes Guidelines for defining attributes. Some of the guidelines for identifying attributes of classes in use cases: Attributes usually correspond to nouns followed by prepositional phrases such as cost of the soup. Attributes also may correspond to adjectives/adverbs
Keep the class simple; state only enough attributes to define the object state
Attributes are less likely to be fully described in the problem statement Omit derived attributes Do not carry discovery of attributes to excessObject Responsibility: Methods and Messages:
Objects not only describe abstract data but also must provide some services Methods and messages are the workhorses of OO system .In an OO environment, every piece of data, or object is surrounded by a rich set of routines called methods. These methods do everything from printing the object to initializing its variables .Every class is responsible for storing certain information from the domain knowledge It also is logical to assign the responsibility for performing any operation necessary on that information. Operations (method/behavior) in the OO system usually correspond to quieries about attributes of the objects.
In other words, methods are responsible for managing the values of attributes such as query, updating, reading and writing.
Defining methods by analyzing UML diagrams and Use cases In a sequence diagram, the objects involved are drawn on the drag as vertical dashed lines, the events that occur between object are drawn between the vertical object lines An event is considered to be an action that transmits information, these action are operation that the object must perform and as in the attributes, methods also can be derived from scenario testing Sequence diagram can assist in defining te services the object must provide.
UNIT-IVDESIGNOO Design Process and Design Axioms
INTRODUCTION Main focus of the analysis phase of SW development what needs to be done
Objects discovered during analysis serve as the framework for design
Classs attributes, methods, and associations identified during analysis must be designed for implementation as a data type expressed in the implementation language
During the design phase, we elevate the model into logical entities, some of which might relate more to the computer domain (such as user interface, or the access layer) than the real world or the physical domain (such as people or employees). Start thinking how to actually implement the problem in a program.
The goal to design the classes that we need to implement the system.
Design is about producing a solution that meets the requirements that have been specified during analysis.
Object-Oriented Design Process and Design Axioms
Analysis Phase
Classs attributes, methods and associations are identified
Physical entities, players and their cooperation are identified
Objects can be individuals, organizations or machines
Design Phase
Using Implementation language appropriate data types are assigned
Elevate the model into logical entities (user interfaces)
Focus is on the view and access classes (How to maintain information or best way to interact with a user)
Importance of Good Design
Time spent on design decides the success of the software developed.
Good design simplifies implementation and maintenance of a project.
To formalize (celebrate, honor) design process, axiomatic (clear) approach is to be followed
Activities of OOD Process
(1).Apply design axioms to design classes, their attributes, methods, associations, structure and protocols.
Refine and complete the static UML class diagram by adding details to the UML class diagram. This steps consists of the following activities: Refine attributes Design methods and protocols by utilizing a UML activity diagram to represent the methods algorithm. Refine association between classes (if required) Refine class hierarchy and design with inheritance (if required). 1.2 Iterate and refine again. (2) Design the access layer
Create mirror classes: For every business class identified and created, create one access layer
Eg , if there are 3 business classes (class1, class2 and class3), create 3 access layer classes (class1DB, class2DB and class3DB)
Identify access layer class relationships
Simplify classes and their relationships main goal is to eliminate redundant classes and structures
Redundant classes: Do not keep 2 classes that perform similar translate request and translate results activities. Select one and eliminate the other.
Method classes: Revisit the classes that consist of only one or two methods to see if they can be eliminated or combined with existing classes.
Iterate and refine again. (3) Design the view layer classes
Design the macro level user interface, identifying view layer objects
Design the micro level user interface, which includes these activities: (a) Design the view layer objects by applying the design axioms and corollaries. (b) Build a prototype of the view layer interface
Test usability and user satisfaction
Iterate and refine
(4) Iterate and refine the whole design. Reapply the design axioms and if needed , repeat the preceding steps.
An axiom is a fundamental truth that always is observed to be valid and for which there is no counterexample or exception.
They can not be proven or derived but they can be invalidated by counterexamples or exceptions.
A theorem is a proposition that may not be self-evident (clear) but can be proved from accepted axioms.
A corollary is a proposition that follows from an axiom or another proposition that has been proven. Types of Axioms AXIOM-1 (Independence axiom): deals with relationships between system components such as classes, requirements, software components.
AXIOM-2 (Information axiom): deals with the complexity of design
Axioms of OOD
The axiom 1 of object-oriented design deals with relationships between system components (such as classes, requirements and software components) and axiom 2 deals with the complexity of design.
Axiom 1. The independence axiom. Maintain the independence of components. According to axiom 1, each component must satisfy its requirements without affecting other requirements. Eg. Let us design a refrigerator door which can provide access to food and the energy lost should be minimized when the door is opened and closed. Opening the door should be independent of losing energy.
Axiom 2. The information axiom. Minimize the information content of the design. It is concerned with simplicity. In object-oriented system, to minimize complexity use inheritance and the systems built in classes and add as little as possible to what already is there. Types of corollaries
The design rules or corollaries derived from design axioms are stated below.
Corollary 1: Uncoupled design with less information content.
Corollary 2: Single purpose.
Corollary 3: Large number of simple classes.
Corollary 4: Strong mapping.
Corollary 5: Standardization.
Corollary 6: Design with inheritance.
Object Storage A database management system (DBMS) is a set of programs that enables the creation & maintenance of a collection of related data.
The fundamental purpose is to provide a reliable, persistent data storage facility & mechanisms for efficient, convenient data access & retrieval
Persistence refers to the ability of some objects to outlive the programs that created them. A program will create a large amount of data throughout its execution.
Each item of data will have a different life time. Atkinson et al. describe six broad categories of life time of data:
Transient results to evaluation of expressions
Variables involved in procedure activation (parameters & variables with a localized scope)
Global variables & variables that are dynamically allocated
Data that exist between the executions of a program
Data that exist between the versions of a program
Data that outlive a program
The first three categories are transient data, data that cease to exist beyond lifetime of creating process. The other three are non-transient or persistent data
A file or a database can provide a longer life for objects longer than duration of process in which they were created. From a language perspective, this characteristic is called persistence. Essential elements in providing a persistent store are
Identification of persistent objects or reachability (object ID)
Properties of objects & their interconnections. The store must be able to coherently manage non-pointer & pointer data (i.e., inter-object references)
Scale of the object store. The object store should provide a conceptually infinite store.
Stability: The system should be able to recover from unexpected failures and return the system to a recent selfconsistent state. This is similar to reliability requirements of a DBMS.
Designing Classes: -
The single most important activity in designing an application is coming up with a set of classes that works together to provide the needed functionality. Underlying the functionality of any application is the quality of its design
OOD Philosophy: A great benefit of OO approach is that classes organize related properties into units that stand on their own. Applying design axioms and carefully designed classes can have a synergistic effect, not only on the current system but on its future evolution
UML OCL: UML is a graphical language with a set of rules & semantics in English in form of OCL. Object Constraint Language (OCL) is specification language that uses simple logic for specifying properties of a system. Syntax of some common navigational expressions is shown here,
Item.selector: The selector is name of an attribute in item. The result is the value of attribute
Item.selector [qualifiervalue]: The selector indicates a qualified association that qualifies the item. Result is related object selected by qualifier, eg., array indexing as form of qualification.
Set select (Booleanexpression): Boolean expression is written in terms of objects within set
Designing Classes The Process: It constitute of step 1 of OOD process is an iterative process and at each iteration, the design has been improved
Class visibility: The main objective is designing well defined public, private & protected protocols
Public protocols define the functionality & external messages of an object; private protocols define implementation of an object
Private Protocol (visibility) of class includes messages that normally should not be sent from other objects. In protected protocol (visibility), subclasses use method in addition to class itself
The problem of encapsulation leakage occurs when details about a classs internal implementation are disclosed through the interface
Refining Attributes: Attributes identified in OOA must be refined on implementation during this phase. In design phase, detailed information must be added to the model. The main goal is to refine existing attributes or add attributes that can elevate the system into implementation.
Attribute Types: The three types of attributes are 1. Singlevalue attributes 2. Multiplicity or multivalue attributes and 3. Reference to another object, or instance connection
UML Attribute representation: The following is attribute presentation suggested by UML
Visibility name: typeexpression = initialvalue where visibility is one of following
+ public visibility (accessibility to all classes)
# protected visibility (accessibility to subclasses & operations of class)
__ private visibility (accessibility only to operations of the class)
Type expression is languagedependent specification of implementation type of an attribute. Initial value is languagedependent expression for initial value of newly created object and is optional. Multiplicity indicated by placing a multiplicity indicator in brackets.
Designing Methods and Protocols: - The main goal of this activity is to specify the algorithm for methods identified so far. A class can provide several types of methods: Constructor, Destructor, Conversion method, Copy method, Attribute set, Attribute get, I/O methods, Domain specific
Use private and protected protocols to define the functionality of the object. Remember five rules to avoid bad design:
1. If it looks messy, then its probably a bad design
2. If it looks too complex, then its probably a bad design
3. If it is too big, then its probably a bad design
4. If people dont like it, then its probably a bad design
5. If it doesnt work, then its probably a bad design Apply design axioms and corollaries to avoid design pitfalls and use UML operation presentation which is similar to syntax of UML attribute representation.
Packages and Managing classes: -
The UML package is grouping of model elements. IT can organize the modeling elements including classes. Packages themselves may be nested within other packages.
A package may contain both other packages and ordinary model elements. The entire system description can be thought of as a single, highlevel sub system package with everything else in it
OOD is an iterative process. Designing is as much about discovery as construction. At each iteration we can improve the design
The advisable trick is to fix the design as early as possible; redesigning late in development cycle is problematic and may be impossible.
System DesignObject-oriented system design involves defining the context of a system followed by designing the architecture of the system.
Context: The context of a system has a static and a dynamic part. The static context of the system is designed using a simple block diagram of the whole system which is expanded into a hierarchy of subsystems. The subsystem model is represented by UML packages. The dynamic context describes how the system interacts with its environment. It is modelled usinguse case diagrams.
System Architecture: The system architecture is designed on the basis of the context of the system in accordance with the principles of architectural design as well as domain knowledge. Typically, a system is partitioned into layers and each layer is decomposed to form the subsystems.
Real Time Example: - Systems which monitor and control their environment
Inevitably associated with hardware devices
Sensors: Collect data from the system environment
Actuators: Change (in some way) the system's environment
Time is critical. Real-time systems MUST respond within specified times
A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced
A soft real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements
A hard real-time system is a system whose operation is incorrect if results are not produced according to the timing specification Stimulus/Response Systems
Given a stimulus, the system must produce a response within a specified time.
For example, a temperature sensor may be polled 10 times per second
Aperiodic stimuli. Stimuli which occur at unpredictable times
For example, a system power failure may trigger an interrupt which must be processed by the system Architectural considerations
Because of the need to respond to timing demands made by different stimuli / responses, the system architecture must allow for fast switching between stimulus handlers
Timing demands of different stimuli are different so a simple sequential loop is not usually adequate Real Time Software Design:
Designing embedded software systems whose behavior is subject to timing constraints To explain the concept of a real-time system and why these systems are usually implemented as concurrent processes
To describe a design process for real-time systems
To explain the role of a real-time executive
To introduce generic architectures for monitoring and control and data acquisition systems Real-time systems:
Systems which monitor and control their environment
Inevitably associated with hardware devices Sensors: Collect data from the system environment Actuators: Change (in some way) the system's environment
Time is critical. Real-time systems MUST respond within specified times Definition:
A real-time system is a software system where the correct functioning of the system depends on the results produced by the system and the time at which these results are produced
A soft real-time system is a system whose operation is degraded if results are not produced according to the specified timing requirements
A hard real-time system is a system whose operation is incorrect if results are not produced according to the timing specification Stimulus/Response Systems:
Given a stimulus, the system must produce a response within a specified time
Periodic stimuli. Stimuli which occur at predictable time intervals For example, a temperature sensor may be polled 10 times per second
Because of the need to respond to timing demands made by different stimuli/responses, the system architecture must allow for fast switching between stimulus handlers
Timing demands of different stimuli are different so a simple sequential loop is not usually adequate
Real-time systems are usually designed as cooperating processes with a real-time executive controlling these processes A real-time system model:
Non-stop system components:
Configuration manager Responsible for the dynamic reconfiguration of the system software and hardware. Hardware modules may be replaced and software upgraded without stopping the systems
Fault manager Responsible for detecting software and hardware faults and taking appropriate actions (e.g. switching to backup disks) to ensure that the system continues in operation Burglar alarm system
e.g A system is required to monitor sensors on doors and windows to detect the presence of intruders in a building
When a sensor indicates a break-in, the system switches on lights around the area and calls police automatically
The system should include provision for operation without a mains power supply Sensors
Movement detectors, window sensors, door sensors.
50 window sensors, 30 door sensors and 200 movement detectors
Voltage drop sensor
When an intruder is detected, police are called automatically.
Lights are switched on in rooms with active sensors.
An audible alarm is switched on.
The system switches automatically to backup power when a voltage drop is detected. The R-T system design process:
Identify stimuli and associated responses
Define the timing constraints associated with each stimulus and response
Allocate system functions to concurrent processes
Design algorithms for stimulus processing and response generation
Design a scheduling system which ensures that processes will always be scheduled to meet their deadlines Control systems:
A burglar alarm system is primarily a monitoring system. It collects data from sensors but no real-time actuator control
Control systems are similar but, in response to sensor values, the system sends control signals to actuators
An example of a monitoring and control system is a system which monitors temperature and switches heaters on and off Data acquisition systems:
Collect data from sensors for subsequent processing and analysis.
Data collection processes and processing processes may have different periods and deadlines.
Data collection may be faster than processing e.g. collecting information about an explosion.
Circular or ring buffers are a mechanism for smoothing speed differences
Reactor data collection:
A system collects data from a set of sensors monitoring the neutron flux from a nuclear reactor.
Flux data is placed in a ring buffer for later processing.
The ring buffer is itself implemented as a concurrent process so that the collection and processing processes may be synchronized. Reactor flux monitoring: Sensors (each data flow is a sensor value) Sensor identifier and value Sensor Sensor data Process process buffer data Mutual exclusion:
Producer processes collect data and add it to the buffer. Consumer processes take data from the buffer and make elements available Reactor data collection:
A system collects data from a set of sensors monitoring the neutron flux from a nuclear reactor.
Flux data is placed in a ring buffer for later processing.
The ring buffer is itself implemented as a concurrent process so that the collection and processing processes may be synchronized. Reactor flux monitoring: Sensors (each data flow is a sensor value) Sensor identifier and value Sensor Sensor data Process process buffer data Mutual exclusion:
Producer processes collect data and add it to the buffer. Consumer processes take data from the buffer and make elements available
Producer and consumer processes must be mutually excluded from accessing the same element. The buffer must stop producer processes adding information to a full buffer and consumer processes trying to take information from an empty buffer System Design. UNIT-VIMPLEMENTATION & ASSURANCEMapping Models to code
Restructuring, optimization and coding
Transformations
1. Model transformations
2. Refactoring
3. Forward engineering
Mapping Associations
Mapping Contracts to Exceptions
Mapping Object Models to Tables
Activities
Developers perform transformations to the object model to improve its modularity and performance and to transform it to the code.
Many of these activities are intellectually not challenging
They have a repetitive and mechanical flavor that makes them error prone.Transformation Principles
Each transformation must address a single criteria
Each transformation must be local
Each transformation must be applied in isolation to other changes
Each transformation must be followed by a validation step.
Refactoring
Improving the design of existing code without affecting its external behavior
Before you start refactoring make sure that you
Test cases
A test case is a set of input data and expected results that exercises a component with the purpose of causing failures and detecting faults.
A test case has five attributes: name, location, input, oracle, and log table.
The name of the test case allows the tester to distinguish between different test cases.
A heuristic for naming test cases is to derive the name from the requirement it is testing or from the component being tested.
For example,
If you are testing a use case Deposit(), you might want to call the test case Test_Deposit. If a test case involves two components A and B, a good name would be Test_AB. The location attribute describes where table Attributes of the class TestCase.
AttributesDescription
nameName of test case
locationFull path name of executable
inputInput data or commands
oracleExpected test results against which the output of the test is compared
logOutput produced by the test
The test case can be found. It should be either the pathname or the URL to the executable of the test program and its inputs.
Input describes the set of input data or commands to be entered by the actor of the test case (which can be the tester or a test driver). The expected behavior of the test case is the sequence of output data or commands that a correct execution of the test should yield.
The expected behavior is described by the oracle attribute. The log is a set of time-stamped correlations of the observed behavior with the expected behavior for various test runs.
Once test cases are identified and described, relationships among test cases are identified.
Aggregation and the precede associations are used to describe the relationships between the test cases.
Aggregation is used when a test case can be decomposed into
