Object Oriented Software Engineering is the planning, design and analysis of software systems before, during and after development. It is code without the code…….and here’s some of what I know about it.
I always liked Object Oriented Software Engineering (OOSENG). It gives you a chance to think. To mentally map out:
- What your system is?
- What should it do?
- What shouldn’t it do?
- What should happen if X occurs?
- Who will use it?
- How will they use is?
- What could go wrong?
Personally, it was a subject that I enjoyed studying and it still is.
OOSENG is effectively the documentation that you have to complete before you embark on a long (and potentially expensive) software design project.
What is Object Oriented Software Engineering (OOSENG)?
In his book, What Every Engineer Should Know about Software Engineering, Phillip Laplante defined Software Engineering as a “systematic approach to the analysis, design, assessment, implementation, test, maintenance and reengineering of software, that is, the application of engineering to software.“
My lecturer, Padraic DeBurca, defined it as (I’m paraphrasing here) ‘everything to write code, right up to the point that you start to code’.
Here is a video
What Are Some Good Online UML Tools?
UML Basic Concepts
UML is part of the Unified Process (UP), which was, or is, a software development process implemented by IBM.
UP identifies the WHO, WHAT and WHEN in a system.
There are 5 Core workflows in UP:
- Requirements – what you need
- Analysis – why and how you need it
- Design – the way you need it
- Implementation – make it
- Test – refine it
There are also 4 process phases in UP:
Since UP is an incremental process, mainly the Elaboration, Construction and Transition phases are divided into a series of iterations.
At the inception phase you initiate the project.
The elaboration phase, outlines the product vision and its architecture.
In the construction phase, the complete the development of the system based upon the baselined architecture is completed.
The transition phase ensures that the software is ready for delivery to its users.
UML Use Cases
To fully understand the purpose of a system you have to know who the system is for, and who will use it.
When designing the System, and specifically when outlining a Use Case, the different types of users are represented by actors.
An ‘actor’ is represented in a Use Case Diagram by a stickman.
Any other system which interacts with the system being developed is also represented by an actor.
For example, if you were doing a Use Case for a Card Payment terminal or device, you would include the customers bank as an actor in your Use Case.
A Use Case represents the functionality of the system and how a person, or even another system, interacts with it.
Use Cases describe HOW a system operates, not the WAY it does it.
An example of a Use Case for an email system, for example, might look something like this:
Use Cases, essentially describe the basic functions of a system. Outlining what the user can do and how the system responds at a high-level.
Use Case Description Template
Each Use Case needs a Use Case description.
The point of the Use Case description is to describe the Use Case‘s flow of events in black-box terms.
- Purpose: The use case’s role in the system.
- Actors: Participating actors and their descriptions.
- Description: A brief summary of the use case
- Flow Description The use case’s behaviour
- Pre-Conditions Condition system should satisfy for UC to start.
- Activation Where the UC starts
- Main Flow
- Alternative Flow(s)
- Exceptional Flow(s)
- Post-Conditions Represents the goals of the UC, if satisfied then UC is valid & successfully completed…
- Views Diagrams related to the use case
- Special Requirements: Provide a detailed description of the non-functional requirements that are scoped to the feature.
- System Characteristics / Performance
- Implementation Requirements Software / Hardware / Documentation
- Technical Specifications
The template above is a general guide to what should be included in a Use Case description. Not every field has to be completed, concentrate on whatever is logical to the Use Case you are working on.