An Introduction To Object Oriented Software Engineering

What is a Good System?

A good system is one which is
Useful & usable
Good software makes peoples lives easier or better

Reliable
Good software has few bugs

Flexible
Users needs change over time, even while software is being developed, so it is important to be able to make changes to the software later

Affordable Available

What is a Good System?

Good software makes peoples lives easier or better

Affordable
Both to buy and maintain

Available
Otherwise it doesnt matter how good it is! Software must be able to run on available hardware, with an available operating system, etc. Software must be delivered as per the commitment 3

Components of Good Systems?

Good Systems consists of
Modules
Module is any identifiable bit of a system which it makes sense to consider separately. Modules can be Files Subroutines Library functions Classes, in an object oriented language

Characteristics of Modules
The following are the various characteristics the module in order to make development and maintenance of systems easy, cheap and reliable They are: Dependency Cohesion Interface Encapsulation Abstraction
5

Characteristics of Modules
Dependency / Coupling Module A depends on Module B if it is possible for some change to Module B to mean that Module A also needs to be changed. A system with many dependencies has high coupling. GOOD SYSTEMS HAVE LOW COUPLING BECAUSE THEN CHANGES TOONE PART OF A SYSTEM ARE LESS LIKELY TOPROPAGET THROUGHOUT THE SYSTEM Cohesion Modules are said to be cohesive when they work together that is changes in Module A does not warrant changes in Module B but together the Module s ensure that combined work they do does not affect other parts of the system
6

Characteristics of Modules
Interface & Encapsulation An interface to a module defines some features of the module on which its clients may rely. The rest of the system can only use the module in ways permitted by the interface(s); That is an interface Encapsulates the knowledge about the module

Characteristics of Modules
A module have several interfaces When we know Module A can sometimes be affected by Changes to Module B, we also want to able to identify as easily as possible what changes are required, if any, in our particular case. Sometimes it is convenient to document the services that module provides as several different interfaces, so that we can be more precise about what
8

Characteristics of Modules
Good Modules often have the property that their interfaces provide an ABSTRACTION of some intuitively understood thing which may nevertheless be complex to implement. The interface abstracts away from the things the client developer does not have to understand in order to use the

Simple Concrete Example of Abstraction and Encapsulation Suppose a module provides an

interface to a point in 2D and that the interface allows clients to get and set the position of the point using either Cartesian co-ordinates or polar coordinates whichever is convenient. Does the module store both set of coordinates and keep them consistent, or does it store one set and use that one to calculate the other on demand? This information is of no interest to client programmers; the module interface should abstract away from it and encapsulate the data structure inside the module. This kind of abstraction 10 and encapsulation is often referred to

 Abstraction is when a client of a module does not need to know more than is in the interface Encapsulation is when a client of a module is not able to know more than is in the interface

Difference between Abstraction & Encapsulation

11

Object Concepts
What is an Object? Conceptually an object is a thing we interact with. We can send messages and it will react How it behaves depends on the current internal state of the object, which may change, as part of the objects reaction to receiving the message

12

Object Concepts
An object has an identity which it distinguishes it from all other objects Hence, an object is a thing which has behavior, state and identity

13

Object Concepts
Thing: An object is a system representation of a conceptual thing. For example, an object may represent a physical thing such as customer, a board or a clock
14

Object Concepts
State: The state of the object is all the data which it currently encapsulates. An object normally has a number of named attributes (or instance variables or data members) each of which has a value. Some attributes can be mutable; that is their values can be changed. For ex. An object representing customer might have an attribute address whose value must change if customer moves out
15

Object Concepts
Behavior: The way an object acts and reacts, in terms of its state changes and message passing. An object understands certain messages, which is to say that it can receive the messages and act on them depending on the current values of the its attributes
16

Object Concepts
Identity: The object have a separate identity of their own. They are not just defined by the current values of their attributes

17

Classes
Class: A class describes a set of objects with an equivalent role or roles in a system. In class based object oriented languages, every object belongs to a class and the class of an object determines its interface
18

Why have Classes?

Classes in object oriented languages serve two purposes. First they are a convenient way of describing a collection (a class) of objects which have the same properties Secondly, classes are used in the same way that types are used in many other language to specify what values are acceptable in given context
19

Inheritance
Inheritance is a technical feature of object oriented language in which a class derives or inherits the properties of the base class. As an example, consider a system in which there is a class whose objects represent lecturers and a class whose objects represents Director of Studies. Now director of studies is also a kind of Lecturer who is also looking into additional duties. Now let us define a new class Directorofstudies which would be a sub class of Lecturer and in 20 addition would have some other

Polymorphism & Dynamic Binding

A polymorphic variable is referred to objects of several different classes. A polymorphic function can take arguments of different types. Dynamic binding refers to the process of identifying what code should be executed as the result of some message
21

 What is UML?

Unified Modeling Language

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.
22

UML
Goals of UML
The primary goals in the design of the UML were: Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. Provide extensibility and specialization mechanisms to extend the core concepts. Be independent of particular programming languages and development processes. Provide a formal basis for understanding the modeling language.
23

UML
Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns and components. Integrate best practices.

24

UML
Why Use UML?
As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance.
25

UML
Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.

26

UML
Basic Building Blocks of UML Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction

27

UML
Use Case Diagram displays the relationship among actors and use cases. Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others.

28

UML
Interaction Diagrams Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects). Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages

29

UML
State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to received stimuli, together with its responses and actions.

30

UML
Activity Diagram displays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal processing.

31

UML
Physical Diagrams Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.
32

UML
Deployment Diagram displays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units.

33

Requirements Elicitation
Requirements Engineering is the first phase of the Software Lifecycle Production of a specification from informal ideas Goal: Requirements Specification System requirements specification: requirements describe Software and Hardware Software requirements specification: describe only Software RE is about what the system should do (not how to do it) Key influencing factor to the development process Failures made here result in high costs in later development phases System will meet the user/customer needs

35

The Use Case Model

A Use Case Model describes the proposed functionality of a new system. A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. This interaction is a single unit of meaningful work, such as Create Account or View Account Details. Each Use Case describes the functionality to be built in the proposed system, which can include another Use Case's functionality or extend another Use Case with its own behavior.

36

The Use Case Model

37

The Use Case Model

A Use Case description will generally includes
General comments and notes describing the use case. Requirements - The formal functional requirements of things that a Use Case must provide to the end user, such as <ability to update order>. These correspond to the functional specifications found in structured methodologies, and form a contract that the Use Case performs some action or provides some value to the system.

38

The Use Case Model

Constraints - The formal rules and limitations a Use Case operates under, defining what can and cannot be done. These include: Pre-conditions that must have already occurred or be in place before the use case is run; for example, <create order> must precede <modify order> Post-conditions that must be true once the Use Case is complete; for example, <order is modified and consistent> Invariants that must always be true throughout the time the Use Case operates; for example, an order must always have a customer number.
39

The Use Case Model

Scenarios Formal, sequential descriptions of the steps taken to carry out the use case, or the flow of events that occur during a Use Case instance. These can include multiple scenarios, to cater for exceptional circumstances and alternative processing paths. These are usually created in text and correspond to a textual representation of the Sequence Diagram. Scenario diagrams - Sequence diagrams to depict the workflow; similar to Scenarios but graphically portrayed. Additional attributes, such as implementation phase, version number, complexity rating, stereotype and status.
40

The Use Case Model

Actors Use Cases are typically related to 'actors', which are human or machine entities that use or interact with the system to perform a piece of meaningful work that helps them to achieve a goal. The set of Use Cases an actor has access to defines their overall role in the system and the scope of their action.

41

The Use Case Model

Includes and Extends relationships between Use Cases One Use Case could include the functionality of another as part of its normal processing. Generally, it is assumed that the included Use Case is called every time the basic path is run. For example, when listing a set of customer orders to choose from before modifying a selected order, the <list orders> Use Case would be included every time the <modify order> Use Case is run. A Use Case can be included by one or more other Use Cases, so it helps to reduce duplication of functionality by factoring out common behavior into Use Cases that are re-used many times.
42

The Use Case Model

One Use Case can extend the behavior of another, typically when exceptional circumstances are encountered. For example, if a user must get approval from some higher authority before modifying a particular type of customer order, then the <get approval> Use Case could optionally extend the regular <modify order> Use Case.

43

The Use Case Model

Sequence Diagrams Sequence diagrams provide a graphical representation of object interactions over time. These typically show a user or actor, and the objects and components they interact with in the execution of a use case. One sequence diagram typically represents a single Use Case 'scenario' or flow of events. Sequence diagrams are an excellent way of documenting usage scenarios and both capturing required objects early in analysis and verifying object use later in design. The diagrams show the flow of messages from one object to another, and as such correspond to the methods and events supported by a class/object.
44

The Use Case Model

The following example of a sequence diagram shows the user or actor on the left initiating a flow of events and messages that correspond to the Use Case scenario. The messages that pass between objects become class operations in the final model.

45

46

An Example: Issue of electronic items

Ecat: Catalog :Library User Lookup Display Issue Issue licence Accept licence Compress Deliver :Library Item Lib1: NetServer

48

Requirements Elicitation Activities

Identify actors Identify scenarios Identify use cases Identify relationships among use cases Refine use cases Identify nonfunctional requirements Identify participating objects

49

Managing Requirements Elicitation

The essential activities and key practices of Requirements Management are: Understand the relationships among key stakeholders and involve them in the requirements engineering process Identify requirements change Recognizing the need for a requirements change is one of the most challenging aspects of project development, and can significantly impact the project. Manage the changes to requirements Establish and use formal procedures of requirements engineering to ensure that issues are addressed and the appropriate specification and communication occurs. Identify and track requirements attributes This provides objective data for better decision making. Trace requirements Maintain an information path from source to implementation.
50

51