Software Engineering Basics Progression of Roles Design Strategies in OO Programming Abstraction Practical Abstraction Better Abstractions Mapping Abstraction to Software Separation of Interface from Implementation Interchangeability of Implementations Specificity of Interface Mapping Abstraction to Software in OO General Structure of a Class General Structure of an Object Multiple Instances of a Class Software Engineering Goals Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Progression of Roles Kafura Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Design Strategies in OO Programming Abstraction modeling essential properties Separation treat what and how independently Composition building complex structures from simpler ones Generalization identifying common elements abstraction separation composition generalization Design Strategies objects classes inheritance templates design patterns Software Structures extensibility flexibility reusability Software Engineering Goals Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Abstraction Modeling entities in software Only essential aspects should be captured attributes behavior Hills, buildings and cossacks with lances. The artist only shows the essential, distinguishing characteristics of each entity. Modeling entities (real world or conceptual) in software An abstraction distills something to its essential properties. The properties that make it what it is and distinguish it from others. Simplifies complex problems Only essential aspects should be included: attributes = properties, characteristics, information behavoir = actions When you say “car,” people get a picture of a generic, or “abstract,” thing with certain properties: wheels, speed, direction, number of passengers, number of axles and behavior: accelerate, brake, stop, turn right, turn left, etc. Wassily Kandinski Cossacks, 1910-11 Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Practical Abstraction Practical abstractions. These shapes convey the essential distinguishing characteristics of a male and female (in our society). Critique?? Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Abstraction A named collection of attributes and behavior relevant to modeling a given entity for some particular purpose. Desirable Properties: well named name conveys aspects of the abstraction coherent makes sense accurate contains only attributes modeled entity contains minimal contains only attributes needed for the purpose complete contains all attributes and behavior needed for the purpose But for software, an abstraction is not a philosophical, ethereal concern. In development, abstractions are refined throughout the life of a piece of software. We start with hand-made lists, and progress through various formal methods, sometimes using software tools. The implementation in source code is the ultimate expression of a software abstraction. Name: to distinguish from other abstractions Attributes and behavior: the essential elements of an abstraction. Modeling: what software is all about Purpose: appropriate abstractions are different for different purposes. Book example of a salesperson abstraction from two perspectives. One is the sales system, number of cars sold is important other is medical system, which couldn’t care less about number sold Well named: clearly conveys aspects of the abstraction Whether it is meaningful depends on the audience. Coherent: makes sense Accurate: contains only the attributes the modeled entity contains. Note VR exception Minimal: only the attributes needed for the purpose of the abstraction. For example, hair color is irrelevant for a billing system. Complete: All the attributes and behavior needed for the purpose of the software. These are all subjective. Judgement through experience are needed. Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

WOMEN MEN Better Abstractions These abstractions illustrates properties of a “good” abstraction: well named (for English-speakers) coherent accurate (culture sensitive representations – Scotland?, ME?) minimal complete Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Mapping Abstraction to Software real-world abstraction software entity attributes behavior {data, data,…} {method, method,…} Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Separation of Interface from Implementation In programming, the independent specification of an interface and one or more implementations of that interface. Interface Implementation visible hidden What is to be done vs How it is to be done What is to be done versus How it is done what/how, goal/plan, policy/mechanism, product/process, ends/means Simpler to express what versus how. Requirements analysis specifies what, programmers implement the how. Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Interchangeability of Implementations Allows the creation of multiple implementations with a common interface. For example: a List ADT could use a dynamic linked list or a dynamic array for the underlying physical data structure. In either case, the same interface would be appropriate (and the user need not be concerned with the underlying structure in many cases). interface implementation2 implementation1 Flexibility. Different implementations can satisfy the same interface. Perhaps the implementations differ in price, reliability, location, etc. Implementations of the same interface are called “plug compatible” Implementations that share a common interface are said to be “plug compatible”. They may differ in algorithmic complexity, reliability, platform dependencies, etc. Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Specificity of Interface Also allows a single implementation to support multiple interfaces. This allows the isolation of restricted set used in one situation versus another LList implementation Stack For example, we could have a very general List ADT that supported both standard List operations, and also Stack operations. By “subsetting” the functionality of the ADT into separate interfaces, we could provide both categories of operation, in a natural way, without duplication of shared code. In essence, we view the implementation as a library of related widgets. An implementation can satisfy more than one interface. This allows the isolation of restricted set used in one situation versus another Suppose there is a more efficient implementation of TextInterface that we want to use in a critical part of the system. Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Mapping Abstraction to Software in OO real-world abstraction OO software entity attributes behavior {data, data,…} {method, method,…} You can model an abstraction in any software language. Prior to O-O, the notion of encapsulating data and operations together was called an Abstract Data Type. But O-O facilitates modeling these kinds of abstractions by using Classes and Objects Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

General Structure of a Class class: a named software representation for an abstraction that separates the implementation of the representation from the interface of the representation A class models an abstraction, which models an entity (possibly “real”). A class represents all members of a group of objects (“instances” of the class). A class provides a public interface and a private implementation. The hiding of the data and “algorithm” from the user is important. Access restrictions prevent idle or malicious alterations. The software model of an abstraction. Class is the definition of the attributes and behavior with implementation. “Class” is used to convey that it represents all members of a group Separation: two parts to a class, public interface, private data and implementation. Hiding data is important so that other developers using the class do not erroneously change it. Hide it and they cannot get to it. Private implementation also hides the algorithm. This is sometimes called “encapsulation.” Class: a named software representation for an abstraction that separates the implementation of the representation from the interface of the representation. Some OO languages do not use classes. E.g., “Self” uses prototypes private public className {data, data, ….} {method,method, …} typical organization Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

General Structure of an Object object: a distinct instance of a given class that encapsulates its implementation details and is structurally identical to all other instances of that class An object “encapsulates” its data and the operations that may be performed on that data. An object’s private data may ONLY be accessed via the member functions defined within the object’s class. An object hides details of representation and implementation from the user. code . data method implementation interface A specific member of a class. Interface and Implementation are separate The object “encapsulates” its data Encapsulation: in o-o programming, the restriction of access to data within an object to only those members defined by the object’s class. Multiple objects are created from a single class definition. Object: A distinct instance of a given class that encapsulates its implementation details and is structurally identical to all other instances of that class. C++ note: Privacy restrictions are enforced at the class level, NOT the object level. That is, if A and B are of the same type, and A knows B’s name, then A can access the private members of B directly. Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Multiple Instances of a Class SalesPerson private public Name commissionRate totalSales sellCar reportSales Joe Hokie 16% $250.000 Jill Hokie $275.000 Each instance, or object, usually has different values for the class-defined properties. Class = Factory Objects = Products Each instance, or object, usually has different values for the class-defined properties. Class=Factory Objects=products Side point (if there’s time) When developing abstractions, or classes, it may help to think of them as people-like entities with responsibilities and collaborators . Responsibilities of knowing (respond with information to a query) Responsibilities of doing (act on something, transform, move, sort, etc.) Collaborators: associated objects in the system with their own responsibilities (association is next week) When developing abstractions, or classes, it may help to think of them as people-like entities with responsibilities and collaborators. Responsibilities of knowing (respond with information to a query) Responsibilities of doing (act on something, transform, move, sort, etc.) Collaborators: associated objects in the system with their own responsibilities Computer Science Dept Va Tech January 2000 ©2000 McQuain WD

Software Engineering Goals Objects and classes help programmers achieve a primary software-engineering goal: reusability A single class is used repeatedly to create multiple object instances. More importantly, encapsulation prevents other developers from inadvertently modifying an object’s data. Separation allows different implementations to be used for an interface. objects classes inheritance templates design patterns Software Structures extensibility flexibility reusability Software Engineering Goals Objects and classes help programmers achieve a primary software-engineering goal: reusability A single class is used repeatedly to create multiple object instances. More importantly, encapsulation prevents other developers from inadvertently modifying an object’s data. Separation allows different implementations to be used for an interface. Computer Science Dept Va Tech January 2000 ©2000 McQuain WD