Object Oriented Analysis and Design

Monday, June 2, 2008

This lecture covers the important aspects of the Object Oriented Analysis and Designing and the entire Software Engineering process. The following is a summary of the lecture which was discussed in detailed at the lecture.


Advantages of Object Oriented Programming

  • Easy to understand
  • Easy for maintenance
  • Reuse of code
  • Reduce development time and cost

Reasons for Software complexity

  • Complexity of Problem domain
  • Difficulty in managing development process
  • Flexibility
  • Contradictionary requirements
  • Impedance mismatches (User/Developer)

Attributes of a complex System

  • Intra component linkages and Inter components linkage
  • Part of Hierarchy
  • Easer Hierarchy

Fundamentals of OOP

  • Object Oriented Analysis
  • Object Oriented Designing

Major elements of Object Model

  • Abstraction
  • Encapsulation
  • Modularity
  • Hierarchy

Advance Software Engineering – Software Complexity and Object Model

Last week ASE lecture was interesting passage of time where the lecture expanded from fundamental to the advanced theories enhancing the knowledge of the students on software engineering, OOA and OOD. There we got some useful points some which we were not having a clear idea to areas we needed to put our focus on. Following is a recap of the lecture.

Object Oriented Programming (OOP)

OOP is an approach to programming which involves the creating of abstracted code pieces/objects designed to interact with each other.The main concept lies with the "Object" to represent the required entities, their interactions and "Classes" or blueprints for object creation.
Few advantages of OOP
  • Permit reusability
    - Inheritance
    - Polymorphism
  • Ease maintainability
  • Secure and Robust
    -Encapsulation
  • Simplicity
  • Extendibility (Scalable)
  • Cost effective

Why software engineers are paid more than other engineering fields?

Rather than other engineering fields the “Software Engineer” has to deal with different domain knowledge with unique set of constrain parameters and able to produce a system which can improve the productivity and efficiency or innovate to capture new value and all these in a dependable responsible manner.

Software development paradox

We have discussed some of the reasons for the complication for the software development process. Software development has been, is, and remains hard due to number of factors.

>>The complexity of the problem domain
Software is developed on variety of domains which involve humans to machine having different prospects of the system. So understanding the problem domain which sometimes alien to the software engineers in a short period of time with other practical restrictions is hard. And the outcome have high expectation and success of a well working system to match the client expectations is difficult.

>>Flexibility aspect of software
Software is much flexible than other tangible engineering outcomes, so the expectations of changing particular requirements is expected. But when accomplishing it shouldn’t harm the other functionality of the system like introducing new buys etc.

>>Difficulties of management
Software is intangible, so monitoring and estimating the progress is difficult (tricky).

>>Impedance mismatch
The user wants/requirements mismatch with the developer understanding of the system which lead to lack of satisfaction of the software. The client may not aware what they want or the developers doesn’t understand what is expected can lead to chaos.

>>Contradictory requirements
Sometimes due to the lack of knowledge to communicate it can lead to contradicting situations which will be not achievable. Maybe the client wants something which can somehow leads to difficulties for the entire system that he may wants.

>>Non-functional requirements
Performance, scalability, usability, reliability and cost like factors which maybe not having a clear understanding can play a major role in the development which incase can lead to contradictions on different parameters such as cost, time and scope.


Factors affection software.







Complexity factors:

Change is unavoidable.

Incrementally changes do not change inherent complexity.

Aggressive refactoring tends to slow down that tendency

Object Model

TheThe object oriented programming concept based on modeling things as objects and using its interactions to interpret real world elements and their behaviors.

OOD revised

The method of designing a software system that leads to object oriented breakdown by using different notations to express different models of the logical and physical design of the system.

Abstraction

In the lecture we talked about one of the most important aspect of OOP, abstraction. It is a concept that emphasizes the essential commonalities of entities while ignoring distinctions. We understood the complexities of understanding the specific features from abstract common feature and how it is useful but difficult to distinguish from a set of objects.

Hierarchy

Complex systems are made up of smaller sub systems which can be represented in hierarchical manner and we can go level by level in detail. These sub system can have sub system within and again we can decompose a complex system in to parts.

Prageeth Kumara - 044025

Lecturer 1 - Object Oriented Design and Analysis

Sunday, June 1, 2008

In the first day I knew why are we paid more, that’s because of the software engineers handle complexity of the software with their brain. Then we move in to the basics of Object Oriented Design and analysis. Because we need to know what are the advantages of Object Oriented Programming. Basics emphasize those factors.

Software that are developed by software engineers are very complex, because

  • It is very difficult to identify problem domain. Software is for particular domain. If we can’t identify that appropriately, it’s difficult to implement functionalities. Consider when develop a software for a bank about financial activities. Then we need to know how transaction handled and its procedure. Sometimes wicked problem arise, means can understand the real problem after it has a solution in initial state.
  • To develop software we have limited resources like time, developers. That can be change time to time.
  • It’s very difficult to see the progress of the project, so Project Managers can’t see the progress in regularly until publish a release. Therefore sometimes projects are stuck at final moment.
  • Software should be flexible up to some extent, because clients expect a system that can change according to their wish before and after system completed. But there should not introduce new bugs to the existing system because of the change.
  • There can be contradictory requirements like the project in tight dead line require engineering hours that are almost same as project duration. Here QA section require another time period for QA Engineering. There can be contradictory things may happen in software development.
  • Impedance mismatch can be occurring between user and developer. When user tell something developer understand it in different way. Sometimes they can’t express clearly what they want. But it can be detecting after implement the system when the user sees the system.
  • Software should be preserve non functional requirements like performance, scalability, maintainability, usability in appropriate manner. That will become a complex task.
  • While developing the software requirement are changing. That is the most common issue in software industry. But because of the amount of resource we have new features should not change the source code, because that may introduce new bugs.

Applying appropriate software engineering for appropriate project phase is the way to reduce this complexity. In software these complexity handle by the software engineers. They provide nice simpler user interface to the users and all the complex things hide from this interface. Users don’t know how the functionality will happen and only knows what has happened.

Then I learnt about the attributes of the computer system.

  • These complex systems can be handled by hierarchies. Here system divides into sub parts which are not complex as main problem. So by solving part by part we can achieve to the solution. Language is a good example, here basic element is letter. By combining letters it can create words then sentence then paragraph then chapter then story and finally a book. There are hierarchies in two types.

Is-a hierarchy (inheritance)

Part-of hierarchy (composition)

  • Among these components relationships are occurring. Here the components in one sub system have intra-component linkage. Components among different subsystems there are inter-component linkage. When comparing these intra-component linkage is stronger than inter-component linkage because there components are in one sub system.
  • It is very important to understand about the problem in Object Oriented basis. Object Oriented Analysis and Design appeared in here. Both of them talk about how to map real world entities to objects. In Object Oriented Analysis identify classes and objects when analyzing requirements and in Object Oriented Design add new classes, design patterns for easier the maintenance process.
  • Abstraction, Encapsulation, Modularity and Hierarchy are major elements of object oriented model.
  • Abstraction is a basic description about something, means it is a concept about something. Here we discussed about abstract things to identify that clearly. Assume vehicle class. It represents common view of a vehicle which has wheels, engine, doors, etc... and can drive, accelerate, brake etc… But it should describe in more specific format when talk about classes like car, bus, etc… Because it should represent special details that can be identified vehicle as car or bus. So when drawing class diagrams each specific class should have specific attributes and behaviors. These specific classes can inherit abstract class and can implement its common methods that are relevant tot each specific class. But it should not repeat same attributes and behaviors in two classes, because it is very difficult to maintain. If that code need to change it should change in every place where it repeat and source code become unnecessarily long. There are many abstract classes like animals, shoe, clothes, aircraft, etc… When represent abstract classes it doesn’t have hierarchies. Also in the situations where things can represent by abstract classes, don’t go to specific classes unnecessarily. It’s depend on the person’s view, means how the person look at the scenario.


  • In Encapsulation we talked about the behaviors that are discussed earlier. Encapsulation means the implementation of those behaviors are hidden. Consider the example as submitAssignment() behavior that we face last four years. We can submit assignment by reading books, accessing internet, copying from another student, etc… Here we don’t show the implementation (how we do the assignment) to the lecturer. That means implementation is hidden.
  • Then we talked about modularity of the software. Simply says software divide and conquer into manageable chunks, so the complexity can be reduced. These different modules are responsible for different activities. The reason for modularity is we can manage and implement each modules without or having minimum effect to other modules. Because modules are divided by reducing inter modular dependencies. So the changes are more effective and manageable.
S.R.S.Gunawardana (044012)

Object Oriented Analysis and Design

Lecture 1



The inherent complexity of software consists from four elements. Those are the complexity of the problem domain, the difficulty of managing the developmental process, the flexibility possible through software, and the problems of characterizing the behavior of discrete systems.

This complexity comes because of the complexity of the problem domain. Some times developers may have to develop a system which they are not familiar with. For example the requirement may be to develop some kind of very accurate medical equipment or an air craft monitoring system. At that situation the developers are from a programming background and not from a medical or aeronautic background. Then they find it difficult to understand the concepts and the requirements the users are expecting. Perhaps there may be contradictory requirements. Nonfunctional requirements such as usability, erformance, cost, survivability, and reliability provide an extra complexity to a system.

This external complexity usually springs from the impedance mismatch that exists between the users of a system and its developers. Users generally find it very hard to give precise expression to their needs in a form that developers can understand. This occurs because each group generally lacks expertise in the domain of the other. Users and developers have different perspectives on the nature of the problem and make different assumptions regarding the nature of the solution.

A further complication is that the requirements of a software system often change during its development process. May be because the users are not aware of the requirements properly. So they change the requirements from time to time when they get the correct vicinity of the system. Seeing early products, such as design documents and prototypes, and then using a system once it is installed and operational, are forcing functions that lead users to better understand and articulate their real needs.

The main objective of the software development process is to make a bib and complex problem domain into a very simple solution where the user can understand and manipulate easily. Developing software writing less code by inventing clever and powerful mechanisms that give us this simplicity, as well as by reusing frame-works of existing designs and code is the most difficult thing in the software development process.

  • Many complex systems are decomposable. Hierarchic structure is a major facilitating factor enabling us to understand by dividing them to subparts and study part by part and then to have a hierarchic structure.
  • What is primitive for one observer may be at a much higher level of abstraction for another.
  • This difference between intra- and inter component interactions provides a clear separation of concerns among the various parts of a system, making it possible to study each part in relative isolation.
  • Most of the big complex systems are developed identifying the common patterns. These patterns may involve the reuse of small components.
  • All the complex systems are evolved from a simple system and we must use them and then improve them over time as we learn more about the real behavior of the system.

Object-oriented analysis

This is a method of analysis of the identified requirements from the perspective of the classes and objects within the problem domain.

Object-oriented design

This is a method of design encompassing the process of object-oriented decomposition and a notation for represents logical and physical as well as static and dynamic models of the system under design.

Abstraction

Abstraction is mainly the process of generalizing which is used as a remedy to the complex requirements. When we are unable to understand a complex system we don’t worry about the unknown parts we just make them abstract. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details which are unimportant for the moment.

Abstraction Types

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 for similar kind of functions.

Virtual machine abstraction

An object that groups together 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

Encapsulation

Encapsulation hides the details of the implementation.

Modularity

Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. The act of partitioning a program into individual components can reduce its complexity to some degree.

Overall goal of the decomposition into modules

  • The simplicity preserves when modularized. It is easy to understand the problem since its divided into small parts.
  • When a problem is modularized its possible to change one module without having a knowledge about the other modules and in the same way a change done to a module may not arises problems in other modules.

— Reduction of software cost by allowing modules to be designed and revised independently

Hierarchy

Hierarchy is a ranking or ordering of abstractions. Hierarchies in our design greatly simplify our understanding of the problem. There are two types of hierarchies. They are ‘is a hierarchy’ and ‘part of hierarchy’.

‘is a hierarchy’

In here Cat is an animal. Dog is an animal. Goat is an animal. Lion is an animal. All belong to the animal class.

‘part of hierarchy’

In here monitor is a part of the computer. Keyboard is a part of the computer. Mouse is a part of the computer. All the three components are in the computer itself and provide different parts of it.



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)

Software Engineering and Object Oriented Analysis & Design

Monday was our first software engineering lecture. During that lecture I got chance to learn new concepts and also to refresh my earlier knowledge.

:-) Software Industry….
Software industry is young industry when comparing to other industries. But this industry has high demand. There are many reasons for that; domain identification is very difficult, progress of the development is invisible, team work ,requirements gathering is very difficult, Basically Software is abstract and intangible.

:-) What makes good software….

Depending on the application user expects different capability from the application. Such as banking systems must secure, a telephone switching system must be reliance etc. These all attributes can be generalized into following attributes. And those are the key Essential attributes of good software such as Maintainability,Dependability,Efficiency,Usability.

:-) New word……

This is new word I head in the lecture and it’s quite interesting .Wicked problem-come up with an initial solution and implements it and see. Like wise you are going forward. Following link gives more details about this Wicked problem

:-) Software and complexity…..

Software is a more complex and also it is an essential property of all large software system. People can develop software but the challenge is developing a industrial-strength software. If we didn’t develop such systems the developed systems are nor more usable. So handling complexity is major task in software industry and there fore we should find a way to tackle this complexity.

We observe that this inherent complexity derives from four elements:

  1. The complexity of the problem domain,
  2. The difficulty of managing the developmental process,
  3. The flexibility possible through software,
  4. The problems of characterizing the behavior of discrete systems.

The complexity of the problem domain

There are lots of root causes to become the problem domain complex. There can be contradictory requirement. This means two or more requirements are complicit each other. Suppose if client ask the product within two week and also he asks for bug free product; this instance shows the contradiction of requirements.

Impedance mismatch is another reason for getting the problem complex. User and developer see the product in different views. In software industry user not able to describe what he wants and same time developer don’t know what user wants. So in this situation requirement gathering is very difficult. Following picture shows famous example of impedance mismatch

And the other thing is requirements are changing during the development process. Normally the large software is evolving with the time. Different users have different requirements so we can’t give generic product.

The difficulty of managing the developmental process,

The user don’t care about how much complex inside the product. So developer responsibility is to give simple solution for the complex problem by hiding the complexity from the user. So developer has to concern about maintainability, flexibility. To achieve this developer have to use different techniques. Also lots of software developments are carried out using team. So managing teams with the development process is also very difficult task .This may get complex when the development work is geographically detached.

The flexibility possible through software

With the software it can be change, add the new things. So flexibility is the thing which we should done the things without introducing new issues or bugs.

The problems of characterizing the behavior of discrete systems.

In general events we may able to describe using the theories. Within the large software application there are lots of variables, thread .So current state of the application is determined by values of these variables. Computers are digital devices with discrete states. So it is very of characterizing the behavior of discrete systems.

Most of the time software industry fails to master the complexity there for software crisis arises. Which means software may not be able to deliver on time and within budget.

There are some complex systems in our environment such as plant, animal, language, human etc.

:-) Attributes of complex system

Normally complex systems are hierarchical and it consists of sub system .Those sub systems are interrelated.The inter-component linkages within a sub system are much stronger than the intra-component linkages. Basically And the complex systems are evolve with the time.

:-) Finished Complexity and discussed about some fundamentals…….

— Object-oriented analysis - Read and identify the objects and classes.

— Object-oriented design - Add more classes, introduce other things not directly related to design and problem domain.

Normally people regard their environment in terms of objects. A model which develops using object oriented technology is often easy to understand because it directly relates to reality.

The following figure shows in object oriented technology has reduced the semantic gap between realty and the model.

:-) What is Object Model?

Object-oriented technology exits on top of foundation and the it consists with some elements.When we take theses elements collectively call the object model.

:-) Major elements of Object Model

During our lecture we discussed about four major elements of object model as mention in the figure.

Abstraction

We identify the object in abstract manner. The level of abstraction depends on the requirement. You have to find the right level of the abstraction in that problem domain .For that you refer the software specification document and find the similarities. Then you can be able to find the right level of abstraction. Also depending on purpose we can reduce the attributes .If not lots of attributes will be in your program and it affect the maintainability of program. There are many abstraction con be find out in our environment such as animal, person, vehicle. Normally Abstract classes cannot be instantiated

:-) Encapsulation

Hide details of implementation of the methods. This picture shows simple example of encapsulation.



Modularity

Best way to handle the complex systems is using divide and conquer method .You divide the whole system into manageable chunk. It will support for maintainability of program. By modularizing you can understand the each module separately.

Hierarchy

Complex systems can be representing in hierarchical manner and we can go level by level in detail. So you able to find sub system and with in that sub system again small sub system like wise you can go along the hierarchy. Within the system as well as among those systems intercommunication take place. You have to minimize inter dependency between the modules. Hierarchy helps to deal the complex problem in simple manner.There are two hierarchy types.

  1. Is-a- : Cat is an animal
  2. Part -of : Monitor is part of Computer

Also there should be a purpose for go to hierarchy. For a simple solution hierarchy may not applicable.

W.Y.M.W.H.E.Wijebandara(044046)



Advanced Softtware Engineering - Lecture 1

Why software is complex ?

  • Complexity of the problem domain - Software is developed to solve a problem. If the problem could be solved simply and easily by human, then there is no need for a software system. So inherently the problems that have to be solved using software systems are complex. Most of the software domains that we come across are different from one another. So their requirements, available resources etc. are different. At the same time even in a particular domain, the knowledge is rapidly changing. So it’s not practical to learn in depth in a particular domain, just to develop the software.

  • Impedance Mismatch - Another major reason for this complexity is the impedance mismatch. The developer of the system doesn’t know what the user really wants and the user doesn’t know how to tell what he really wants. The users and developers are having different perspectives regarding the problem and they provide different assumptions about the nature of the problem.

  • Difficulty of managing the development process - If you are building a house you can see how it is being built. You can see the foundation is being laid; walls are building, then the roof and so on. So at any given point of a time it can be said what are the things completed and what more to be done. Managing is easy.But when it comes to software, it is intangible. You cannot see how it grows, so as to measure and manage the development process. At the initial stages you will feel that the project is on track and all the things are going smoothly, but when you reach the deadlines you recognise that lot more to be done but limited time.

On the other hand when the size of the system is getting bigger the management of it is too difficult. (Here we are talking about the hundreds and thousands of lines of code and sometimes millions of lines of code).

  • The flexibility possible through software -When we are building a house it is highly unlikely that we will change the structure in the halfway though. Even we does, it will cost a lot. Since software offers ultimate flexibility, it is possible to change the designs, requirements etc. during the development cycle.

  • Requirement of a software system often changes during the development - Changing requirement and the features during the development cycle is a common thing. Some times the users do not have a proper idea of what they want. When they see the system being developed half way through, they realise what they really needed. From the developers’ side, as and when they develop they get a better understanding of the domain and will find better ways to do. These may come out as new features or as improvements. Both these reasons cause the changing requirements during the development cycle.

  • Non Functional Requirements - When it comes to software, only the functionality is not enough. The users expect something more from a software system. Non-functional requirements such as usability, performance, scalability etc. are important. In addition to the functionality of the system, the developers have to pay attention on these areas as well. So managing both of these requirements is not an easy job.


The role of the Software Engineer...

The role of the software engineer is to hide this complexity from the user and provide a simplified view to use. For an example every time when we are getting money from ATM, what if we (as the users) have to call the bank and ask whether sufficient money is in the account, after that again do a check to see whether the sufficient amount is there with the ATM machine etc. The system has hidden all those complex things from the user, and when the user enters the amount, it will provide money or a message.


Attributes of a complex system

Normally complex systems are formed in a form of a hierarchy. There are small sub systems that are inter-related and within those sub systems there are further sub systems and so on. But there is an elementary component which all the sub systems are made out of. The inter-component linkages within a sub system are much stronger than the intra-component linkages which are present among sub systems. The complex systems are developed by evolving. It as to be designed from the scratch and cannot be patched up to make it work.


OOP Recap

Object Oriented Analysis

Object oriented analysis is the method of analysing the requirements in a form of an object model.


Object Oriented Design

Object oriented design is the method of designing the system that leads to object oriented decomposition by using different notations to express different models of the logical (class and object structure) and physical (module and process architecture) design of the system.


Abstraction

Abstraction denotes the essential characteristics that should be present to distinguish one object from another. The level of abstraction depends on the way we are using it. For an example tree can be an abstract in a system that deals with botanical details, but it may not be the case in another system.


Duleepa Karunaratne (044021)