Advanced Software Engineering - Object Oriented Analysis & Design Concepts

In summary, during our first lecture we had a basic introduction to the essential concepts of Software Engineering which has been misunderstood by many students. So at the first we were asked three questions such as why object oriented programming (OOP) is needed? What are the advantages of learning and using OOP? What are the other options that we have?

OOP is needed Because of the growing complexity of software development. In OOP, whole software is described in terms of the objects or the concepts and their relations. OOP leads to:

• Reuse, and reuse (of program components) leads to faster software development and higher-quality programs
• Higher maintainability of software since its structure is inherently decoupled
• Develop systems that are easier to extend and easier to scale without changing the existing implementation. So the work that has been tested will not be affected by the new insertions to the system, hence it saves the cost of the software development and maintenance in many ways.

Then basically we discussed about the essential elements of the Software Engineering by sticking to the following major topics:

1. The Inherent Complexity of Software

Why software engineers are paid more?
Software engineers are modeling projects whereas engineers are building projects. Developing a Software Project is much more complex than the developing any other tangible project like building. Since the nature of intangibility of software, it is very harder to monitor and measure the progress of software project.

Most of the time software engineers develop systems based on other’s requirements in different domains which are not familiar to them previously. So developing the right system that complies with the client requirements for a given domain is a complex task. The complexity associated with the software projects can be further discussed in terms of the followings.

The Complexity of the Problem Domain - Software systems are developed in order to cater for various domains. Domains can be quite large, for instance “Medical,” “Legal”. Software engineers are not familiar with those domains, and hence they have to learn about those concepts within a very short time period prior to begin the real implementation. This can be very crucial if the problem domain is changing rapidly.

The Difficulty of Managing the Development Process - Since the software systems are intangible it’s enormously harder to monitor the progress of the project during the development process.
Note: Wicked Problem - Sometimes during the development of the software project, developers have to come up with a solution though they haven’t fully understood the problem yet. These are kind of a wicked problems.

The Flexibility Possible Through Software - As software is much more flexible compared to other tangible products like building, clients may request lots of rapid changes while the problem is being solved. If we are not developing the project in a structured manner tackling those client requests may introduce new bugs to the system.

Contradictory requirements - Since it’s harder to translate the thoughts in mind in to set of words, there is chance to appear contradictory requirements from multiple clients.

Impedance mismatch between users - Most of the time clients may not sure about what they want and developers also don’t know what the clients want from them. Developing the system according to the developer perspective will not fulfill the client requirement.

Non functional requirements - Functional requirements specify what the system should essentially do whereas non-functional requirements specify how the system should behave while operating. Those non-functional requirements can be software specific and achieving them makes the software development more complex. Examples of such requirements are:
• Portability • Reliability • Performance • Testability • Modifiability • Reusability • Interoperability

Requirement change during its development - Although that is very rare in other engineering projects, software tends to be changed during its development process with the understanding of the system. Most of the changes are proposed by the clients of the system when they get knowledge about the system gradually.

All these things makes software engineering different from problem solving in other engineering fields and sciences. How does software engineer deal with complexity in large projects?

• Divide and conquer
• Abstraction (Modeling), decomposition, hierarchy
• Iterate and increment
• Reuse and recycle
• Strong cohesion and low coupling
  – Among different subsustems within the system

Next we discussed about the attributes of a complex system:

2. Attributes of a complex system

Hierarchical Structure: Complex systems are structured to describe the function of its sub systems as well as the hierarchic relationship among these sub systems.

Relative Primitives: The choice of what components in a system are primitive is largely up to the judgment of the observer of the system.
Separation of Concerns: Intra-component linkages are generally stronger that inter-component linkages.

Common Patterns: Hierarchic systems are usually composed of only a few different kinds of sub-systems in various combinations and arrangements.

Stable Intermediate Forms: Complex systems designed from scratch never works so we have to start over, beginning with a working simple system.

Finally we talked more about the essential principles of Object Orientation

3. Basic Principles of Object Orientation - Elements of an object model

Object-Oriented Analysis - OOA is concerned with developing software engineering requirements and specifications that expressed the whole software system as a group of interacting objects within the problem domain. "OOA focuses on what the system does"

Object-Oriented Design - OOD is concerned with the concepts in the analysis model and mapped onto implementation classes and interfaces. "OOD focuses on how the system does".

In OOP, the basic conceptual framework is the object model. There are four major elements of this model:

Abstraction

Abstraction is a kind of representation of a concept that emphasizes the essential commonalities of entities while ignoring distinctions. Some of the examples for abstractions are animal, vehicle, furniture, shoe, food, etc…If we take the concept of “Animal”, when we define abstract data; we identify their essential characteristics as follows, since the consideration is to identify the similarities and to ignore for the time being the differences. In this abstract view of the Animal we only have essential attributes and operations that are common to all the other animals so we can’t instantiate objects out of that. Simply means if we are asked to draw an animal which has these properties we can’t.

As software engineer often faces the question seeing that how to identify useful objects from a requirement specification. Although it is crucial to identify the right level of abstraction, that can lead the most extendable and maintainable software implementation. Also it allows us to manage the complexity associated with the system. Abstraction is totally depends on the domain and perspective of the software to be implemented.

Encapsulation

While abstraction helps to focus on the essential characteristics of an object, encapsulation enables to expose only those details that are necessary to effectively use the object. This is achieved through information hiding. Clients of particular software totally depend on the interfaces, so encapsulation helps software engineers to hide the details of the implementation of the interface by revealing as little as possible about the inner workings of the Interface to the clients.

Example: it is not important for an automobile purchaser to know the inventory cost of an automobile but it is important for the purchaser to know the purchase price. Encapsulation allows us to hide the inventory cost but allows access to the purchase price based on client requirement.

Additionally encapsulation helps for minimizing interdependencies among modules by defining strict external interfaces. This way, internal coding can be changed without affecting the interface, so long as the new implementation supports the same (or compatible) external interface. It prevents a program from becoming so interdependent that a small change has massive effects. In this way with the use of this technique we can change the implementation of an object without affecting the application that uses it for.

Modularity

Modularity allows physical and logical decomposition of large and complex things into smaller and manageable components.

This allows software engineers to decompose a large chunk of a system into small and manageable subsystems in a loosely coupled manner. The subsystems can be independently developed and compiled as long as their interactions with other modules are well understood. By modularizing the software we can tackle the complexity associated with it easily. But inter module dependencies within the system should be minimal.

Hierarchy

Hierarchy is a ranking or ordering of abstractions. The two important hierarchies in an OO system are:

U. W. D. Dilhani (044007)