Successfully reported this slideshow.
Your SlideShare is downloading. ×

20CB304 - SE - UNIT V - Digital Notes.pptx

Pleasereadthis disclaimer before proceeding:
This document is confidential and intended solely for the educational purpose...
Digital Notes
20CB304 Software Engineering
Department: CSBS
Batch/Year: 2021-25/II
Created by: Mr.B.Jayaram/AP
Date: 24.07...
To understand the different models and milestones in a software project
To understand fundamental concep...

Check these out next

1 of 50 Ad

More Related Content

Recently uploaded (20)


20CB304 - SE - UNIT V - Digital Notes.pptx

  1. 1. Pleasereadthis disclaimer before proceeding: This document is confidential and intended solely for the educational purpose of RMK Group of Educational Institutions. If you have received this document through email in error, please notify the system manager. This document contains proprietary information and is intended only to the respective group / learning community as intended. If you are not the addressee you should not disseminate, distribute or copy through e-mail. Please notify the sender immediately by e-mail if you have received this document by mistake and delete this document from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contentsof this information is strictlyprohibited.
  2. 2. Digital Notes 20CB304 Software Engineering Department: CSBS Batch/Year: 2021-25/II Created by: Mr.B.Jayaram/AP Date: 24.07.2022
  3. 3. COURSE OBJECTIVES To understand the different models and milestones in a software project To understand fundamental concepts of software project management To understand the various software design methodologies To learn various testing and maintenance measures To understand knowledge driven development PREREQUISITE 20IT101 Fundamentals of Computer Science 20IT201 Data Structures and Algorithms
  4. 4. 20CB304 SYLLABUS Software Engineering L T P C 3 2 2 5 UNIT I INTRODUCTION 9 Programming in the small vs. programming in the large; software project failures and importance of software quality and timely availability; engineering approach to software development; role of software engineering towards successful execution of large software projects; emergence of software engineering as a discipline. Basic concepts of life cycle models different models and milestones. Software Quality and Reliability: Internal and external qualities; process and product quality; principles to achieve software quality; introduction to different software quality models like McCall, Boehm, FURPS / FURPS+, Dromey, ISO – 9126; introduction to Capability Maturity Models (CMM and CMMI); introduction to software reliability, reliability models and estimation UNIT II SOFTWARE PROJECT MANAGEMENT 9 Software project planning –identification of activities and resources; concepts of feasibility study; techniques for estimation of schedule and effort; software cost estimation models and concepts of software engineering economics; techniques of software project control and reporting; introduction to measurement of software size; introduction to the concepts of risk and its mitigation; configuration management. DESIGN AND 9 UNIT III SOFTWARE REQUIREMENTS ANALYSIS, CONSTRUCTION Introduction to Software Requirements Specifications (SRS) and requirement elicitation techniques; techniques for requirement modelling – decision tables, event tables, state transition tables, Petri nets; Requirements documentation through use cases; Introduction to UML, introduction to software metrics and metrics based control methods; measures of code and design quality.
  5. 5. SYLLABUS 20CB304 Software Engineering L 3 T P C 2 2 5 UNIT IV SOFTWARE TESTING 9 Introduction to faults and failures; basic testing concepts; concepts of verification and validation; black box and white box tests; white box test coverage – code coverage, condition coverage, branch coverage; basic concepts of black-box tests – equivalence classes, boundary value tests, usage of state tables; testing use cases; transaction-based testing; testing for non- functional requirements – volume, performance and efficiency; concepts of inspection. UNIT V Object Oriented Analysis, Design and Construction: 9 Concepts -- the principles of abstraction, modularity, specification, encapsulation and information hiding; concepts of abstract data type; Class Responsibility Collaborator (CRC) model; quality of design; design measurements; concepts of design patterns; Refactoring; object oriented construction principles; object oriented metrics. TOTAL: 45 PERIODS
  6. 6. Course Outcomes Course Code Course Outcome Statement Cognitive/ Affective Level of the Course Outcome Expected Level of Attainment Course Outcome Statements in CognitiveDomain CO1 Identify the key activities in managing a software project. Understand K2 70% CO2 Manage project schedule, estimate project cost and effort required. Analyse K4 70% CO3 Summarize the concepts of software requirement analysis and design . Understand K2 70% CO4 Identify the need for software metrics and measure of code and design quality. Analyse K4 70% CO5 Compare and contrast various testing methodologies. Analyse K4 70% CO6 Analyze Knowledge driven development and problem space understanding Analyse K4 70%
  7. 7. (CO s) Programme Outcomes (POs), Programme Specific Outcomes(PSOs) PO 1 PO 2 PO 3 PO 4 PO 5 PO 6 PO 7 PO 8 PO 9 PO 10 PO 11 PO 12 PS O1 PS O2 PS O3 CO1 3 2 1 1 3 3 3 3 3 CO2 3 3 2 2 3 3 3 3 3 CO3 2 1 2 3 3 3 CO4 3 2 1 1 3 3 3 3 3 CO5 3 3 2 2 3 3 3 3 3 CO6 3 2 1 1 3 3 2 2 2 9 Correlation Matrix of the Course Outcomes to Programme Outcomes and Programme Specific Outcomes Including Course Enrichment Activities CO-PO/PSO Mapping
  8. 8. UNIT V Object Oriented Analysis, Design and Construction 10 Object-Oriented Programming Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships. There are three important parts to this definition: (1) Object-oriented programming uses objects, not algorithms, as its fundamental logical building; (2) each object is an instance of some class; and (3) classes may be related to one another via inheritance relationships. A program may appear to be object-oriented, but if any of these elements is missing, it is not an object-oriented program. Specifically, programming without inheritance is distinctly not object oriented; that would merely be programming with abstract data types. A language is object-oriented if and only if it satisfies the following requirements:  It supports objects that are data abstractions with an interface of named operations and a hidden local state.  Objects have an associated type [class].  Types [classes] may inherit attributes from supertypes [super classes]. Object-Oriented Design Object-oriented design is a method of design encompassing the process of object- oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design. There are two important parts to this definition: object-oriented design (1) leads to an object-oriented decomposition and (2) uses different notations to express different models of the logical (class and object structure) and physical (module and process architecture) design of a system, in addition to the static and dynamic aspects of the system.
  9. 9. Object-Oriented Analysis Object-oriented analysis (OOA) emphasizes the building of real-world models, using an object-oriented view of the world: Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain. How are OOA, OOD, and OOP related? Basically, the products of object-oriented analysis serve as the models from which we may start an object-oriented design; the products of object-oriented design can then be used as blueprints for completely implementing a system using object- oriented programming methods. Elements of the object model Programming style Programming style as “a way of organizing programs on the basis of some conceptual model of programming and an appropriate language to make programs written in the style clear”. There are five main kinds of programming styles, listed here with the kinds of abstractions they employ: There is no single programming style that is best for all kinds of applications. For example, rule-oriented programming would be best suited for the design of a knowledge base, and procedure-oriented programming would be best for the design of computation-intense operations. From our experience, the object-oriented style is best suited to the broadest set of applications; indeed, this programming paradigm often serves as the architectural framework in which we employ other paradigms. 11
  10. 10. Each of these styles of programming is based on its own conceptual framework. Each requires a different mindset, a different way of thinking about the problem. For all things object-oriented, the conceptual framework is the object model. There are four major elements of this model: 1. Abstraction 2. Encapsulation 3. Modularity 4. Hierarchy By major, we mean that a model without any one of these elements is not object- oriented. There are three minor elements of the object model: 1. Typing 2. Concurrency 3. Persistence By minor, we mean that each of these elements is a useful, but not essential, part of the object model. 1.Concepts -- the principles of abstraction, modularity, specification, encapsulation and information hiding 1. The Meaning of Abstraction An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer. Abstraction focuses on the essential characteristics of some object, relative to the perspective of the viewer. 12
  11. 11. “There is a spectrum of abstraction, from objects which closely model problem domain entities to objects which really have no reason for existence”. From the most to the least useful, these kinds of abstractions include the following: Entity abstraction An object that represents a useful model of a problem domain or solution domain entity. Action abstraction An object that provides a generalized set of operations, all of which perform the same kind of function. Virtual machine abstraction An object that groups operations that are all used by some superior level of control, or operations that all use some junior-level set of operations. Coincidental abstraction An object that packages a set of operations that have no relation to each other. Some more points on abstraction A client is any object that uses the resources of another object (known as the server). We can characterize the behavior of an object by considering the services that it provides to other objects, as well as the operations that it may perform on other objects. Central to the idea of an abstraction is the concept of invariance. An invariant is some Boolean (true or false) condition whose truth must be preserved. For each operation associated with an object, we may define preconditions (invariants assumed by the operation) as well as postconditions (invariants satisfied by the operation). Violating an invariant breaks the contract associated with an abstraction. 13
  12. 12. If a precondition is violated, this means that a client has not satisfied its part of the bargain, and hence the server cannot proceed reliably. Similarly, if a postcondition is violated, this means that a server has not carried out its part of the contract, and so its clients can no longer trust the behavior of the server. An exception is an indication that some invariant has not been or cannot be satisfied. All abstractions have static as well as dynamic properties. For example, a file object takes up a certain amount of space on a particular memory device; it has a name, and it has contents. These are all static properties. The value of each of these properties is dynamic, relative to the lifetime of the object: A file object may grow or shrink in size, its name may change, its contents may change. Fig. 5.1 Abstraction of a temperature sensor What are the responsibilities of a temperature sensor? Our design decision is that a sensor is responsible for knowing the temperature at a given location and reporting that temperature when asked. More concretely, what operations can a client perform on a temperature sensor? Our design decision is that a client can calibrate it, as well as ask what the current temperature is. 5.1.2 The Meaning of Encapsulation The abstraction of an object should precede the decisions about its implementation. Once an implementation is selected, it should be treated as a secret of the abstraction and hidden from most clients. 14
  13. 13. Abstraction and encapsulation are complementary concepts: Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior. Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods. “No part of a complex system should depend on the internal details of any other part”. Whereas abstraction “helps people to think about what they are doing,” encapsulation “allows program changes to be reliably made with limited effort. “Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation”. 5.1.3 The Meaning of Modularity The act of partitioning a program into individual components can reduce its complexity to some degree. . . . Although partitioning a program is helpful for this reason, a more powerful justification for partitioning a program is that it creates a number of well-defined, documented boundaries within the program. “Modularization consists of dividing a program into modules which can be compiled separately, but which have connections with other modules”. In traditional structured design, modularization is primarily concerned with the meaningful grouping of subprograms, using the criteria of coupling and cohesion. In object-oriented design, the problem is subtly different: The task is to decide where to physically package the classes and objects, which are distinctly different from subprograms. 15
  14. 14. The overall goal of the decomposition into modules is the reduction of software cost by allowing modules to be designed and revised independently. . . . Each module’s structure should be simple enough that it can be understood fully; it should be possible to change the implementation of other modules without knowledge of the implementation of other modules and without affecting the behavior of other modules; [and] the ease of making a change in the design should bear a reasonable relationship to the likelihood of the change being needed”. We strive to build modules that are cohesive (by grouping logically related abstractions) and loosely coupled (by minimizing the dependencies among modules). From this perspective, we may define modularity as follows: Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. 5.1.4 The Meaning of Hierarchy A set of abstractions often forms a hierarchy, and by identifying these hierarchies in our design, simplify understanding of the problem. We define hierarchy as follows: Hierarchy is a ranking or ordering of abstractions. The two most important hierarchies in a complex system are its class structure (the “is a” hierarchy) and its object structure (the “part of” hierarchy). Examples of Hierarchy: Single Inheritance inheritance defines a relationship among classes, wherein one class shares the structure or behavior defined in one or more classes (denoting single inheritance and multiple inheritance, respectively). Inheritance thus represents a hierarchy of abstractions, in which a subclass inherits from one or more super classes. Typically, a subclass augments or redefines the existing structure and behavior of its super classes. 16
  15. 15. Inheritance denotes an “is a” relationship. For example, a bear “is a” kind of mammal, a house “is a” kind of tangible asset, and a quick sort “is a” particular kind of sorting algorithm. Inheritance thus implies a generalization/ specialization hierarchy, wherein a subclass specializes the more general structure or behavior of its super classes. The litmus test for inheritance: If B is not a kind of A, then B should not inherit from A. As we evolve our inheritance hierarchy, the structure and behavior that are common for different classes will tend to migrate to common superclasses. This is why we often speak of inheritance as being a generalization/specialization hierarchy. Superclasses represent generalized abstractions, and subclasses represent specializations in which fields and methods from the superclass are added, modified, or even hidden. In this manner, inheritance lets us state our abstractions with an economy of expression. Indeed, neglecting the “is a” hierarchies that exist can lead to bloated, inelegant designs. “Without inheritance, every class would be a free- standing unit, each developed from the ground up. Different classes would bear no relationship with one another, since the developer of each provides methods in whatever manner he chooses. Examples of Hierarchy: Multiple Inheritance For certain abstractions, it is useful to provide inheritance from multiple superclasses. For example, we can define a Rose class (see Figure 5.2) that inherits from both Plant and FlowerMixin. Instances of the subclass Rose thus include the structure and behavior from the class Plant together with the structure and behavior from the class FlowerMixin. 17
  16. 16. Similarly, a Carrot class could be as shown in Figure 5.3. In both cases, we form the subclass by inheriting from two superclasses. Figure 5.2:The Rose Class, Which Inherits from Multiple Superclasses Figure 5.3:The Carrot Class, Which Inherits from Multiple Superclasses Multiple inheritance is conceptually straightforward, but it does introduce some practical complexities for programming languages. Languages must address two issues: clashes among names from different superclasses and repeated inheritance. Clashes will occur when two or more superclasses provide a field or operation with the same name or signature as a peer superclass. 18
  17. 17. Examples of Hierarchy: Aggregation The “is a” hierarchies denote generalization/specialization relationships, “part of” hierarchies describe aggregation relationships. For example, consider the abstraction of a garden. We can contend that a garden consists of a collection of plants together with a growing plan. In other words, plants are “part of” the garden, and the growing plan is “part of” the garden. This “part of” relationship is known as aggregation. Aggregation is not a concept unique to object-oriented development or object- oriented programming languages. Indeed, any language that supports record-like structures supports aggregation. However, the combination of inheritance with aggregation is powerful: Aggregation permits the physical grouping of logically related structures, and inheritance allows these common groups to be easily reused among different abstractions. In terms of its “is a” hierarchy, a high-level abstraction is generalized, and a low- level abstraction is specialized. Therefore, we say that a Flower class is at a higher level of abstraction than a Plant class. In terms of its “part of” hierarchy, a class is at a higher level of abstraction than any of the classes that make up its implementation. Thus, the class Garden is at a higher level of abstraction than the type Plant, on which it builds. Aggregation raises the issue of ownership. Our abstraction of a garden permits different plants to be raised in a garden over time, but replacing a plant does not change the identity of the garden as a whole, nor does removing a garden necessarily destroy all of its plants (they are likely just transplanted). In other words, the lifetime of a garden and its plants are independent. In contrast, we have decided that a GrowingPlan object is intrinsically associated with a Garden object and does not exist independently. Therefore, when we create an instance of Garden, we also create an instance of GrowingPlan; when we destroy theGarden object, we in turn destroy the GrowingPlan instance. 19
  18. 18. 5.1.5 The Meaning of Typing “A type is a precise characterization of structural or behavioral properties which a collection of entities all share”. Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways. A given programming language may be strongly typed, weakly typed, or even untyped, yet still be called object-oriented. For example, Eiffel is strongly typed, meaning that type conformance is strictly enforced: Operations cannot be called on an object unless the exact signature of that operation is defined in the object’s class or superclasses. Examples of Typing: Static and Dynamic Typing The concepts of strong and weak typing and static and dynamic typing are entirely different. Strong and weak typing refers to type consistency, whereas static and dynamic typing refers to the time when names are bound to types. Static typing (also known as static binding or early binding) means that the types of all variables and expressions are fixed at the time of compilation; dynamic typing (also known as late binding) means that the types of all variables and expressions are not known until runtime. A language may be both strongly and statically typed (Ada), strongly typed yet supportive of dynamic typing (C++, Java), or untyped yet supportive of dynamic typing (Smalltalk). Polymorphism is a condition that exists when the features of dynamic typing and inheritance interact. Polymorphism represents a concept in type theory in which a single name (such as a variable declaration) may denote objects of many different classes that are related by some common superclass. Any object denoted by this name is therefore able to respond to some common set of operations [74]. The opposite of polymorphism is monomorphism, which is found in all languages that are both strongly and statically typed. Polymorphism is perhaps the most powerful feature of object-oriented programming languages next to their support for abstraction, and it is what distinguishes object- oriented programming from more traditional programming with abstract data types. 20
  19. 19. 5.1.6 The Meaning of Concurrency Systems executing across multiple CPUs allow for truly concurrent threads of control, whereas systems running on a single CPU can only achieve the illusion of concurrent threads of control, usually by means of some time-slicing algorithm. We also distinguish between heavyweight and lightweight concurrency. A heavyweight process is one that is typically independently managed by the target operating system and so encompasses its own address space. A lightweight process usually lives within a single operating system process along with other lightweight processes, which share the same address space. Communication among heavyweight processes is generally expensive, involving some form of interprocess communication; communication among lightweight processes is less expensive and often involves shared data. Whereas object-oriented programming focuses on data abstraction, encapsulation, and inheritance, concurrency focuses on process abstraction and synchronization. Concurrency is the property that distinguishes an active object from one that is not active. one of the realities about concurrency is that once its introduce it into a system, consider how active objects synchronize their activities with one another as well as with objects that are purely sequential. For example, if two active objects try to send messages to a third object, we must be certain to use some means of mutual exclusion, so that the state of the object being acted on is not corrupted when both active objects try to update its state simultaneously. This is the point where the ideas of abstraction, encapsulation, and concurrency interact. In the presence of concurrency, it is not enough simply to define the methods of an object; we must also make certain that the semantics of these methods are preserved in the presence of multiple threads of control. 21
  20. 20. 5.1.7 The Meaning of Persistence An object in software takes up some amount of space and exists for a particular amount of time. In most systems, an object, once created, consumes the same physical memory until it ceases to exist. However, for systems that execute on a distributed set of processors, we must sometimes be concerned with persistence across space. In such systems, it is useful to think of objects that can move from machine to machine and that may even have different representations on different machines. Persistence is the property of an object through which its existence transcends time (i.e., the object continues to exist after its creator ceases to exist) and/or space (i.e., the object’s location moves from the address space in which it was created). 5.2 Concepts of Abstract Data Type An abstract data type (ADT) is a mathematical model for data types. An abstract data type is defined by its behavior (semantics) from the point of view of a user, of the data, specifically in terms of possible values, possible operations on data of this type, and the behavior of these operations. This mathematical model contrasts with data structures, which are concrete representations of data, and are the point of view of an implementer, not a user. Formally, an ADT may be defined as a "class of objects whose logical behavior is defined by a set of values and a set of operations“. Example A well-known and convenient example is the description of stack objects. A stack object serves to pile up and retrieve other objects in a last-in, first-out (“LIFO”) manner, the latest inserted element being the first one to be retrieved. The stack is a ubiquitous structure in computing science and in many software systems; the typical compiler or interpreter, for example, is peppered with stacks of many kinds. 22
  21. 21. Stack representations Several possible physical representations exist for stacks: ARRAY_UP: represent a stack through an array representation and an integer count whose value ranges from 0 (for an empty stack) to capacity, the size of the array representation; stack elements are stored in the array at indices 1 up to count. ARRAY_DOWN: like ARRAY_UP, but with elements stored from the end of the array rather than from the beginning. Here the integer is called free (it is the index of the highest free array position, or 0 if all positions are occupied) and ranges from capacity for an empty stack down to 0. The stack elements are stored in the array at indices capacity down to free + 1. LINKED: a linked representation which stores each stack element in a cell with two fields: item representing the element, and previous containing a pointer to the cell containing the previously pushed element. The representation also needs last, a pointer to the cell representing the top. Fig. 5.4 Three possible representations for a stack 23
  22. 22. Next to each representation, the figure shows a program extract (in Pascal-like notation) giving the corresponding implementation for a basic stack operation: pushing an element x onto the top. For the array representations, ARRAY_UP and ARRAY_DOWN, the instructions increase or decrease the top indicator (count or free) and assign x to the corresponding array element. Since these representations support stacks of at most capacity elements, robust implementations should include guards of the respective forms. For LINKED, the linked representation, pushing an element requires four operations: Create a new cell n (done here with Pascal’s new procedure, which allocates space for a new object); assign x to the new cell’s item field; chain the new cell to the earlier stack top by assigning to its previous field the current value of last; and update last so that it will now be attached to the newly created cell. Using the operations The operations typically available on a stack are the following: • A command to push an element on top of a stack. Let us call that operation put. • A command to remove the stack’s top element, if the stack is not empty. Let us call it remove. • A query to find out what the top element is, if the stack is not empty. Let us call it item. • A query to determine whether the stack is empty. (This will enable clients to determine beforehand if they can use remove and item.) 24
  23. 23. Formalizing the specification An abstract data type specification will provide the following information. • TYPES. • FUNCTIONS. • AXIOMS. • PRECONDITIONS. Specifying types what is a type? A type is a collection of objects characterized by functions, axioms and preconditions. an abstract data type such as STACK is not an object (one particular stack) but a collection of objects (the set of all stacks). An object belonging to the set of objects described by an ADT specification is called an instance of the ADT. For example, a specific stack which satisfies the properties of the STACK abstract data type will be an instance of STACK. Our specification is about a single abstract data type STACK, describing stacks of objects of an arbitrary type G. Genericity In STACK [G], G denotes an arbitrary, unspecified type. G is called a formal generic parameter of the abstract data type STACK, and STACK itself is said to be a generic ADT. The mechanism permitting such parameterized specifications is known as genericity. Listing the functions After the TYPES paragraph comes the FUNCTIONS paragraph, which lists the operations applicable to instances of the ADT. As announced, these operations will 25
  24. 24. be the prime component of the type definition — describing its instances not by what they are but by what they have to offer. Below is the FUNCTIONS paragraph for the STACK abstract data type. Each line introduces a mathematical function modeling one of the operations on stacks. For example function put represents the operation that pushes an element onto the top of a stack. Operation put, for example, is specified as which means that put will take two arguments, a STACK of instances of G and an instance of G, and yield as a result a new STACK [G]. (More formally, the source set of function put is the set STACK [G] X G, known as the cartesian product of STACK [G] and G; this is the set of pairs <s, x> whose first element s is in STACK [G] and whose second element x is in G.) Here is an informal illustration: 26
  25. 25. The role of the operations modeled by each of the functions in the specification of STACK is discussed below. •Function put yields a new stack with one extra element pushed on top. The figure on the preceding page illustrates put (s, x) for a stack s and an element x. •Function remove yields a new stack with the top element, if any, popped; like put, this function should yield a command at design and implementation time. We will see below how to take into account the case of an empty stack, which has no top to be popped. • Function item yields the top element, if any. • Function empty indicates whether a stack is empty; its result is a boolean value (true or false); the ADT BOOLEAN is assumed to have been defined separately. • Function new yields an empty stack. The FUNCTIONS paragraph does not fully define these functions; it only introduces their signatures — the list of their argument and result types. The signature of put is STACK [G] X G - STACK [G] indicating that put accepts as arguments pairs of the form <s, x> where s is an instance of STACK [G] and x is an instance of G, and yields as a result an instance of STACK [G]. The signature of functions remove and item includes a crossed arrow instead of the standard arrow used by put and empty. This notation expresses that the functions are not applicable to all members of the source set. The AXIOMS paragraph The AXIOMS paragraph states the properties. For STACK it will be: 27
  26. 26. The first two axioms express the basic LIFO (last-in, first-out) property of stacks. T o understand them, assume we have a stack s and an instance x, and define s' to be put (s, x), that is to say the result of pushing x onto s. Here axiom A1 tells us that the top of s' is x, the last element that we pushed; and axiom A2 tells us that if we remove the top element from s', we get back the stack s that we had before pushing x. These two axioms provide a concise description of the fundamental property of stacks in pure mathematical terms. Axioms A3 and A4 tell us when a stack is empty and when it is not: a stack resulting from the creator function new is empty; any stack resulting from pushing an element on an existing stack (empty or not) is non- empty. Preconditions For STACK, the paragraph will appear as: where, for each function, the require clause indicates what conditions the function’s arguments must satisfy to belong to the function’s domain. The boolean expression which defines the domain is called the precondition of the corresponding partial function. Here the precondition of both remove and item expresses that the stack argument must be non-empty. The complete specification It is given in the figure 5.5. FROM ABSTRACT DATA TYPES TO CLASSES In the search for a good modular structure based on object types, abstract data types provide a high-level description mechanism, free of implementation concerns. They will lead us to the fundamental structures of object technology. 28
  27. 27. Fig. 5.5 Complete ADT Specification of stacks Classes ADTs will serve as the direct basis for the modules, More precisely, an object- oriented system will be built (at the level of analysis, design or implementation) as a collection of interacting ADTs, partially or totally implemented. The basic notion here is class: So to obtain a class we must provide an ADT and decide on an implementation. The ADT is a mathematical concept; the implementation is its computer-oriented version. The definition, however, states that the implementation may be partial; the following terminology separates this case from that of a fully implemented class: 29
  28. 28. To obtain an effective class, you must provide all the implementation details. For a deferred class, you may choose a certain style of implementation but leave some aspects of the implementation open. In the most extreme case of “partial” implementation you may refrain from making any implementation decision at all; the resulting class will be fully deferred, and equivalent to an ADT. How to produce an effective class Consider first the case of effective classes. What does it take to implement an ADT? Three kinds of element will make up the resulting effective class: E1 • An ADT specification (a set of functions with the associated axioms and preconditions, describing the functions’ properties). E2 • A choice of representation. E3 • A mapping from the functions (E1) to the representation (E2) in the form of a set of mechanisms, or features, each implementing one of the functions in terms of the representation, so as to satisfy the axioms and preconditions. Many of these features will be routines (subprograms) in the usual sense, although some may also appear as data fields, or “attributes”. For example, if the ADT is STACK, we may choose as representation (step E2) the solution called ARRAY_UP above, which implements any stack by a pair <representation, count> where representation is an array and count an integer. For the function implementations (E3) we will have features corresponding to put, remove, item, empty and new, which achieve the corresponding effects; for example we may implement put by a routine of the form 30
  29. 29. The role of deferred classes For an effective class, all of the implementation information (E2, E3 above) must be present. If any of it is missing, the class is deferred. The more deferred a class, the closer it is to an ADT. Abstract data types and information hiding The ADT view of a module under information hiding is shown below. If the module is a class coming from an ADT as outlined above, the answer is clear: of the three parts involved in the transition, E1, the ADT specification, is public; E2 and E3, the choice of representation and the implementation of the ADT functions in terms of this representation, should be secret. Fig. 5. 6 ADT view of a module 31
  30. 30. 5. 3 Class Responsibility Collaborator (CRC) model For completeness it is necessary to mention an idea that is sometimes quoted as a technique to find classes. CRC cards (Class, Responsibility, Collaboration) are paper cards, 4 inches by 6 inches (10.16 centimeters by 15.24 centimeters), on which designers discuss potential classes in terms of their responsibilities and how they communicate. The idea has the advantage of being easy on the equipment budget (a box of cards is typically cheaper than a workstation with CASE tools) and of fostering team interaction. Its technical contribution to the design process — to helping sort out and characterize valuable abstractions. A CRC card is a standard index card that has been divided into three sections. Fig. 5. 7 CRC Model A class represents a collection of similar objects. An object is a person, place, thing, event, concept, screen, or report that is relevant to the system at hand. Figure 5.8 shows a shipping/inventory control system with the classes such as Inventory Item, Order, Order Item, Customer, and Surface Address. The name of the class appears across the top of the card. A responsibility is anything that a class knows or does. For example, customers have names, customer numbers, and phone numbers. These are the things that a customer knows. Customers also order products, cancel orders, and make payments. 32
  31. 31. These are the things that a customer does. The things that a class knows and does constitute its responsibilities. Responsibilities are shown on the left hand column of a CRC card. Sometimes a class will have a responsibility to fulfill, but will not have enough information to do it. When this happens it has to collaborate with other classes to get the job done. For example, an Order object has the responsibility to calculate it’s total. Although it knows about the Order Item objects that are a part of the order, it doesn’t know how many items were ordered (Order Item knows this) nor does it know the price of the item (Inventory Item knows this). Fig. 5. 8 A CRC Model for a simple shipping/inventory control system To calculate the order total, the Order object collaborates with each Order Item object to calculate its own total, and then adds up all the totals to calculate the overall total. For each Order Item to calculate its individual total, it has to collaborate with Inventory Item to determine the cost of the ordered item, multiplying it by the number ordered (which it does know). The collaborators of a class are shown in the right-hand column of a CRC card. Cards that collaborate with one another are close to each other, cards that don’t collaborate are not near each other. 33
  32. 32. 5.5 Quality of design 34 Design creates a representation or model of the software, the design model provides detail about software architecture, data structures, interfaces, and components that are necessary to implement the system. Software design sits at the technical kernel of software engineering and is applied regardless of the software process model that is used. Beginning once software requirements have been analyzed and specified, software design is the first of three technical activities—design, code generation, and test—that are required to build and verify the software. Each activity transforms information in a manner that ultimately results in validated computer software. The importance of software design can be stated with a single word—quality. Design is the place where quality is fostered in software engineering. Design provides us with representations of software that can be assessed for quality. Design is the only way that we can accurately translate a customer's requirements into a finished software product or system. Software design serves as the foundation for all the software engineering and software support steps that follow.. THE DESIGN PROCESS Software design is an iterative process through which requirements are translated into a “blueprint” for constructing the software. Throughout the design process, the quality of the evolving design is assessed with a series of formal technical reviews or design walkthroughs. Reviews for measuring design and associated documentation During a review, several people examine the software and its associated documentation, looking for potential problems and nonconformance with standards. The review team makes informed judgments about the level of quality of the software or project documents. Project managers may then use these assessments to make planning decisions and allocate resources to the development process. Quality reviews are based on documents that have been produced during the software development process. As well as software specifications, designs, code, process models, test plans, configuration management procedures, process standards, and user manuals may all be reviewed.
  33. 33. 5.5 Quality of design & design measurements 35 The review should check the consistency and completeness of the documents or code under review and, if standards have been defined, make sure that these quality standards have been followed. Reviews are not just about checking conformance to standards. They are also used to help discover problems and omissions in the software or project documentation. The conclusions of the review should be formally recorded as part of the quality management process. If problems have been discovered, the reviewers’ comments should be passed to the author of the software or whoever is responsible for correcting errors or omissions. The purpose of reviews and inspections is to improve software quality, not to assess the performance of people in the development team. Reviewing is a public process of error detection, compared with the more private component-testing process. Inevitably, mistakes that are made by individuals are revealed to the whole programming team. To ensure that all developers engage constructively with the review process, project managers have to be sensitive to individual concerns. They must develop a working culture that provides support without blame when errors are discovered. Progress reviews compare the actual progress in a software project against the planned progress. Their prime concern is whether or not the project will deliver useful software on time and on budget. Design Walkthrough A "walkthrough" is a review of a product/system by peers: the participants, who are approximately at the same level in the organization, meet to review and discuss systematically a piece of software. Here, we study a software design from the perspective of the user. The "Structured Walkthrough"s (Yourdon, 1979) have been proven to be one of the most effective methods to obtain feedback and improve the quality of software. The rules are very simple but very important: the groups must be small (3 to 7 persons),
  34. 34. group members must be of the same level, the presenter must prepare work in advance, everyone must be on time, and the session should be limited to one hour maximum. The purpose of the walkthrough is to identify as many problems as possible, not to discuss possible solutions . Critiques must be as positive as possible and should be limited to the part presented by the presenter. 36 a specific role for each walkthrough. be presented Presents it to the group Roles: Each group member has Presenter: Selects that which must Scribe: Takes note of the comments. Coordinator: Ensures that the discussion is concentrated on the software Ensures that the session lasts exactly x minutes (max 1 hour). Guardian of standards: Asks questions based on the specifications of the project. Preparation: Make several copies of your scenario (one for each member of your group, plus one copy to cut if you reuse text). Procedure: The presenter acknowledges scenario and organizes screenshots (or videos) that are necessary for a user to perform each step of the scenario. The scribe notes the basic information on the attached page. Result: Move so that everyone can see images of the presenter screen. The presenter begins by describing the scenario quickly and present the first image that the user sees. He or she shows what the user needs to do, step by step, to execute the script. At each step, the examiners/participants will ask questions and make constructive criticism of each screen or the general usability of the software. Do not criticize the authors, focus on the prototype. The scribe should make a list of design issues that were identified and include them in the report. At the end, the group must decide if the software is acceptable, or if it needs minor or major revisio
  35. 35. 5.6 Design Measurements 37 To see how these measurements reveal information about the design, design measurements can be based on three different characteristics: (i) Relationships between classes (e.g., friendship, inheritance), (ii) Types of interactions between classes (e.g., class–attribute interaction, class– method interaction, method–method interaction), and (iii) Due to design changes (i.e., whether a change flows toward or away from a class). For each class in a design, they defined metrics that count the interactions between the class and other classes or methods. Then, using empirical information about the design for a real system and the resulting system’s faults and failures, they analyzed the relationship between the type of coupling and the kinds of faults that were found. For example, they report that when a class depended on a large number of attributes that belonged to other classes that were not ancestors, descendants, or friends of that class, then the resulting code was more fault prone than usual. Similarly, when many methods belonging to friend classes depended on the methods of a particular class, then that class was more fault prone. In this way, design information can be used to predict which parts of the software are most likely to be problematic. We can take steps during the design stage to build in fault prevention or fault tolerance, and we can focus more of our initial testing efforts on the most fault-prone parts of the design.
  36. 36. 5.7 concepts of design patterns 38 The concept of a pattern was first originated in the field of Architecture, where large buildings are designed in specific pattern solutions. This concept has now been absorbed in the area of object-oriented design to provide a very powerful mechanism for design reuse. Design patterns and their role in OOAD While working out the design solution to a problem, experienced designers consciously or unconsciously reuse solutions that they might have worked out in the past. Such reuse of the design solutions is systematized by the concept of patterns. In fact, patterns allow commonly accepted solutions to be reused by everybody familiar with the patterns. what are design patterns? Design patterns are commonly accepted solutions to some problems that recur during designing different applications. Design patterns are nowadays being used extensively and have been found to make the design process efficient. Use of patterns reduces the number of design iterations, and at the same time improves the quality of the final design solution. Basic Pattern Concepts The basic idea behind patterns is that if you can master a few important patterns, you can easily spot them in application development problems and effortlessly use the pattern solutions. Patterns can be viewed as helping designers to make certain important design decisions. At a basic level, patterns can also be viewed as well-documented and well thought-out building blocks for software design.
  37. 37. A pattern documentation usually consists of four important parts:  The problem.  The context in which the problem occurs.  The solution.  The context within which the solution would work and would not work. Patterns versus algorithms “Are patterns and algorithms identical concepts? After all, both target to provide reusable solutions to problems!” In fact, patterns and algorithms are in some respects similar since both attempt to provide reusable solutions. However, algorithms primarily focus on solving problems with reduced space and/or time requirements, whereas patterns focus on understandability and maintainability of design and easier development. 39 to improve Pros and cons of design patterns The following are the main pros strengths of design patterns:  Design patterns provide a common vocabulary that helps communication among the developers.  Design patterns help to capture and disseminate expert knowledge.  Use of design patterns help designers to produce designs that are flexible, efficient, and easily maintainable.  Design patterns guide developers to arrive at correct design decisions and help them to improve the quality of their designs.  Design patterns reduce the number of design iterations, and help improve the designer productivity. Important cons shortcomings of design patterns are the following:  Design patterns do not directly lead to code reuse. Since a design pattern is tailored for a specific circumstance of reuse, and therefore it is difficult to
  38. 38. associate a fixed code segment with a pattern. At present no methodology is available that can be used to select the right design pattern at the right point during a design exercise. Classification of Design Patterns Design patterns vary in their granularity and level of abstraction. Because there are many design patterns, we need a way to organize them. This section classifies design patterns so that we can refer to families of related patterns. The classification helps you learn the patterns in the catalog faster, and it can direct efforts to find new patterns as well. Design patterns are classified by two criteria. The first criterion, called purpose, reflects what a pattern does. Patterns can have either creational, structural, or behavioral purpose.  Creational patterns concern the process of object creation.  Structural patterns deal with the composition of classes or objects.  Behavioral patterns characterize the ways in which classes or objects interact and distribute responsibility. The second criterion, called scope, specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static— fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. So the only patterns labeled "class patterns" are those that focus on class relationships. Note that most patterns are in the Object scope. 40
  39. 39. Design Pattern Space Example EXPERT PATTERN Problem: When a certain activity needs to be performed, which class should be made responsible for doing it? Solution: Assign responsibility to the information expert—the class that has all (or most of) the information necessary to fulfill the required responsibility. The expert pattern expresses the common intuition that objects should do things related to the information they store. The class and collaboration diagrams for the solution to a problem as to which class should compute the total cost of a sale transaction is shown in Figure 5.9. Explanation: In the example given in Figure 5.9, a sale transaction consists of many sale items. Each saleItem object is associated with an itemSpecification object. The itemSpecification object among other things indicates the unit price for the item. 41
  40. 40. In this situation, which object should compute the total price for a sale transaction? Let us consider the different options that are available. Should the saleTransaction object, the saleItem object, or the itemSpecification object be given the responsibility to compute the price of a sale transaction? If we assign the responsibility to the saleItem object to compute the transaction price, then it would need several information from the saleTransaction object such as the number of items sold for various items and could also need the prices for the other items from the corresponding itemSpecification objects for this computation. Figure 5.9: Expert pattern: (a) Class diagram (b) Collaboration diagram This would require a large number of data exchanges among the objects to occur, and lead to a poor quality solution. Similarly, itemSpecification would be a poor choice for computing the total cost payable for a sale transaction, since the object lacks most of the information required to compute the total cost of the transaction. It can easily be seen that the saleTransaction object has most of the information required for the computation, and should be assigned the responsibility to compute the total price. It is the information expert, as far as the exact items and quantities sold are concerned. 42
  41. 41. 5.8 Refactoring 43 An important design activity suggested for many agile methods, refactoring is a reorganization technique that simplifies the design (or code) of a component without changing its function or behavior. “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure.” When software is refactored, the existing design is examined for redundancy, un- used design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better design. For example, a first design iteration might yield a component that exhibits low cohesion (i.e., it performs three functions that have only limited relationship to one another). After careful consideration, you may decide that the component should be refactored into three separate components, each exhibiting high cohesion. Why Should You Refactor? Refactoring Improves the Design of Software Refactoring Makes Software Easier to Understand Refactoring Helps You Find Bugs Refactoring Helps You Program Faster When Should You Refactor? Refactor when You add new feature/function Refactor When You Need to Fix a Bug Refactor As You Do a Code Review Problems with Refactoring Databases One problem area for refactoring is databases. Most business applications are tightly
  42. 42. coupled to the database schema that supports them. That's one reason that the database is difficult to change. Another reason is data migration. Even if you have carefully layered your system to minimize the dependencies between the database schema and the object model, changing the database schema forces you to migrate the data, which can be a long and fraught task. 9. object oriented construction principles (Refer Unit 1 of Object oriented programming) 10. object oriented metrics. object-oriented metrics is specifying ones that provide meaningful measures to support the analysis and design of software systems. Metrics fall into one of two categories,  process metrics  product metrics. Process metrics, sometimes called project metrics, assist the management team in assessing progress with respect to the object-oriented development process being used. Examples of process metrics include the number of person-hours expended, the amount of work accomplished, and the number of project dollars spent—all compared to what was planned. Metrics more specific to object-oriented development. Application size – Number of scenario scripts (NSS) – Number of key classes (NKC) – Number of support classes (NSC) – Number of subsystems (NOS) 44
  43. 43. Staffing size – Person-days per class (PDC) –Classes per developer (CPD) Scheduling – Number of major iterations (NMI) – Number of contracts completed (NCC) We tend to measure development progress by counting the classes in the logical design, or the components in the physical design, that are completed and working. Product metrics (sometimes called design metrics) It helps the development team assess the artifacts of their analysis and design efforts, rather than on process metrics. Number of language-independent design metrics that are directly applicable to object-oriented systems are.  Weighted methods per class (WMC)  Depth of inheritance tree (DIT)  Number of children (NOC)  Coupling between object classes (CBO)  Response for a class (RFC)  Lack of cohesion in methods (LCOM) Weighted methods per class gives the sum of the complexities of each of the methods of an individual class. If all the method complexities are considered to be equally complex, this becomes a measure of the number of methods per class. In general, a class with significantly more methods than its peers is more complex, tends to be more application-specific, and often hosts a greater number of defects. 45
  44. 44. The depth of the inheritance tree and number of children are measures of the shape and size of the class structure. Well-structured object-oriented systems tend to be architected as forests of classes, rather than as one very large inheritance tree. The depth of the inheritance tree, measured from the subject class to its highest-level parent class, gives a measure of the impact to it from inheriting functionality. Therefore, a deeper inheritance tree increases the complexity of a class, due to the functionality it inherits. Looking down the inheritance tree, we see the number of children for the subject class. The more children a class has, the greater its impact on the software system’s design, due to the reuse it produces. Coupling between objects is a measure of their connectedness to other objects and thus is a measure of their class’s encumbrance. As with traditional measures of coupling, we seek to design loosely coupled objects, which have a greater potential for reuse. Response for a class is a measure of the methods that its instances can execute in response to a message call. In general, a class that has significantly more methods that can be invoked, compared with its peers, is more complex. Lack of cohesion in methods is a measure of the unity of the class’s abstraction. A class with low cohesion among its methods suggests an accidental or inappropriate abstraction; such a class should generally be re-abstracted into more than one class or its responsibilities delegated to other existing classes. 46
  45. 45. Part-B Questions Q. No. Questions CO Level K Level 1 Discuss in detail about the various elements of object model with example. CO6 K2 2 Discuss in detail about the concepts of Hierarchy. CO6 K2 3 Explain the following minor elements of object model in detail with an example. (i) Typing (ii) Concurrency (iii) Persistence CO6 K2 4 Discuss in detail about the concepts of abstract datatype with a programming example? CO6 K4 5 Discuss in detail about the classes responsibility collaborator (CRC) model with an example? CO6 K2 6 Explain in detail about the concepts of design pattern and its various types? CO6 K4 7 What are the various object-oriented construction principles? Discuss in detail? CO6 K2 8 Explain in detail about the object-oriented metrics? CO6 K3
  46. 46. Part-A Questions Q. No. Questions CO Level K Level 1 What is object-oriented programming? CO6 K2 2 Mention the requirements to be followed for a language is to be called as an object-oriented? CO6 K2 3 Define object-oriented design? CO6 K2 4 What are the five main kinds of programming style? CO6 K2 5 Mention the minor elements of the object model? CO6 K2 6 What are the various kinds of abstraction? CO6 K2 7 Define Aggregation with an example? CO6 K2 8 Define Persistence? CO6 K2 9 What is meant by refactoring? CO6 K2 10 What are the various object oriented metrics? CO6 K2
  47. 47. PRESCRIBED TEXT BOOKS AND REFERENCE BOOKS TEXT BOOKS: 1.Software Engineering, Ian Sommerville Chrome- extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html?pdfurl=http%3A%2F% 2Findex- pdf&clen=14566720&chunk=true 2.Fundamentals of Software Engineering, Carlo Ghezzi, Jazayeri Mehdi, Mandrioli Dino. 3.Software Requirements and Specification: A Lexicon of Practice, Principles andPrejudices, Michael Jackson REFERENCE BOOKS: 1. Software Metrics: A Rigorous and Practical Approach, Norman E Fenton, Shari Lawrence Pfleeger 2. Software Engineering: Theory and Practice, Shari Lawrence Pfleeger and Joanne M. Atlee 3. UML Distilled: A Brief Guide to the Standard Object Modeling Language -- Martin Fowler 4. Object-Oriented Software Construction, Bertrand Meyer 5. The Unified Development Process, Ivar Jacobson, Grady Booch, James Rumbaugh 6. Design Patterns: Elements of Object-Oriented Reusable Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 49
  48. 48. Disclaimer: This document is confidential and intended solely for the educational purpose of RMK Group of Educational Institutions. If you have received this document through email in error, please notify the system manager. This document contains proprietary information and is intended only to the respective group / learning community as intended. If you are not the addressee you should not disseminate, distribute or copy through e-mail. Please notify the sender immediately by e-mail if you have received this document by mistake and delete this document from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in relianceon thecontentsof this informationisstrictly prohibited. Thankyou