Object Architecture Philosophy – If you were to start from scratch, how would you architect your object model and why

It revolves around many related concepts, models and patterns. Primary principle will be to achieve the primary objective that is to develop the application, which will meet the entire requirement. Now the question will arises:

• How ease to build to implement the design?
• How much time is required?
• What is cost?
• How it will be maintained?
• Is it a tempering proof?
• Whether this is scalable?
• What will be Load balancing factor?
• Performance wise acceptable or not?

Enterprise Application architecture can be viewed in separate angles as follows:

• Business architecture: the business processes and supporting organizational structure
• Application/software architecture: the architecture of applications that support the business processes
• Technology architecture: addressing the infrastructure that supports the applications
• Information/data architecture: addressing the information that supports the applications

The whole process is having the following steps:

• Conception
• Decomposition
• Analysis
• Design
• Coding
• Implementation
• Maintenance

The whole process can follow either the waterfall model, spiral model or prototype model but on top of this certain principles can be implemented for achieving the ultimate feasible solution. That is the object oriented principles. While doing any of the job we need to keep in mind the background process regarding the object oriented principles i.e. concept of reusability, abstraction, encapsulation, polymorphism.

If we consider the analysis we see OOA, for designing OOD, for selecting language OOL, for programming OOP. In this whole process the key thing is the architecture which bridges between the requirements and implementation. Now implementation comprises two components:

• Modeling which can be understood by the programmers/developers i.e. Internal Users, conceptual as well as implementation point of view; I mean to say that the developer can understand clearly to create the expected by using the appropriate technologies. It should be technically perfect.
• The ultimate application which will be useful to the end user i.e. External Users. It should be functionally efficient.

The key words of this topic are as follows:

(a)  “Object Architecture Philosophy”

(b) “Start from scratch”

(c)  “Architect your object model and why”

Objective: Software Quality in terms of following Factors

Object-oriented techniques enhance key external and internal software quality factors, e.g.,

• External
• Correctness
• Robustness and reliability
• Performance
• Internal
• Modularity
• Flexibility/Extensibility
• Reusability
• Compatibility (via standard/uniform interfaces)

What is the rationale for using OO?

In general, systems evolve and functionality changes, but objects and classes tend to remain stable over time

“Object Architecture Philosophy”

All through OO

OOA, OOD, OOL and OOP – all these are OOs.

Object-oriented methods may be applied to different phases in the software lifecycle e.g., analysis, design, implementation, etc.

• OO Analysis (OOA) is a process of discovery; where a development team models and understands the requirements of the system. Analysis emphasizes an investigation of the problem and requirements, rather than a solution. “Analysis” is a broad term, best qualified, as in requirements analysis (an investigation of the requirements) or object analysis (an investigation of the domain objects).
• OO Design (OOD) is a process of invention and adaptation; where the development team creates the abstractions and mechanisms necessary to meet the system's behavioral requirements determined during analysis. Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. A critical, fundamental ability in OOA/D is to skillfully assign responsibilities to software components.
• OO Programming (OOP)

“Start from scratch”

Prerequisite for architecting

• OOA / OOD / OOP concepts
• About the System modeling tool
• Design Pattern
• The concepts of UML
• Concept of Domain-Specific Language (DSL)
• Object Role Modeling (ORM)

The whole process is broken down into the following steps.

Understand the system properly - Functionally

• Conception
• Decomposition
• Requirement Analysis

For requirement analysis we will definitely draw the use case diagram as well as write down in the text specification also. (Presently, what we are following for V2020 project)

Prior to go through in detail into the design

Find out the Design Pattern

We will try to find out the appropriate match with the current problem and existing design pattern’s problem specs. If it will not match with a particular one then we will try to design based on that experience.

But in reality it’s very much impossible to get same type of problem spec. In this scenario better we will go through the patterns which are closely same to the current problem. Then we will try to integrate into one pattern.

Architect the System

Draw the Class Diagram and also sequence diagram

These two diagrams are very important to map the problem to the solution.

Also we would like to architect the system keeping into the mind these following things:

• Components as Assets of the organization which should be domain specific as well as same thing will work independently.
• Modularity
• Scalable
• Better performance oriented
• Flexible
• Easy to understand and easy to maintain
• Finally, well structured

“Architect your object model and why”

Why architecture with OO methods?

OO methods provide a set of techniques for analyzing, decomposing, and modularizing software system architectures. In general, OO methods are characterized by structuring the system architecture on the basis of its objects (and classes of objects) rather than the actions it performs

Main purpose of these design concepts is to manage software system complexity by improving software quality factors. This provides the following benefits

• Helps to focus on large-scale system design
• Separation of design concerns
• Can identify good domain-specific architectures
• Design abstraction
• Have a common language
• Managerial basis for cost estimation & process mgmt
• Reuse
• Consistency and dependency analysis
• Technical basis for design

OO Modeling of an Solution

• Identifying Objects of Interest from the Model
• Associating Attributes with Objects of Interest
• Specify how the objects, and interactions and interrelationships among the objects, will effect a solution to the problem

Types Model

(a)    Textual Models

These are textual descriptions of both individual objects and systems of objects.

(b)   Graphical Models

These graphically represent the characteristics of individual objects or systems of objects.

(c)    Class-Responsibility-Collaboration Cards (CRC Cards)

Where do Objects come from?

The following are potential sources of objects:

• The model itself, e.g.:
• Written documents
  paragraph, the nouns, pronouns, noun phrases, adjectives, adjectival phrases, adverbs, and adverbial phrases will suggest candidate objects.
• Graphical model
  certain objects may be implied by such things as nodes and communication among the nodes.
• The information supplied by the OORA(Object Oriented Requirement Analysis) process
• The mind of the software engineer
• A study of existing objects in an object library
• Technical references, e.g., books and articles

Object Modeling using UML

There are three prominent aspects of the modeled system that are handled by UML:

• Functional Model

It describes the functionality of the system from the user's Point of View.

It’s through Use Case Diagrams.

• Object Model

It showcases the structure and substructure of the system using objects, attributes, operations, and associations.

It’s through Class Diagrams.

• Dynamic Model

It showcases the internal behavior of the system.

It’s through Sequence Diagrams, Activity Diagrams and Statechart Diagrams

Use Case model

• Provide an overview of all or part of the usage requirements for a system or organization in the form of an model or a business model
• Communicate the scope of a development project
• Model the analysis of the usage requirements in the form of a system use case model

Use Cases are used primarily to capture the high level user-functional requirements of a system. The Use Case model is about describing “what” the system will do at a high-level and with a user focus for the purpose of scoping the project and giving the application some structure.

Class Diagram

It shows the classes of the system, their inter-relationships, and the operations and attributes of the classes.  Class diagrams are used to:

• Explore domain concepts in the form of a domain model
• Analyze requirements in the form of a conceptual/analysis model
• Depict the detailed design of object-oriented or object-based software

Object Sequence Diagram

Object Sequence Diagrams are about deciding and modeling HOW our system will achieve WHAT we described in the Use Case model.

It’s a dynamic modeling technique. UML sequence diagrams are typically used to:

• Validate and flesh out the logic of a usage scenario.
• Explore the design because they provide a way to visually step through invocation of the operations defined by the classes.
• To detect bottlenecks within an object-oriented design.  By looking at what messages are being sent to an object, and by looking at roughly how long it takes to run the invoked method, you quickly get an understanding of where need to change the design to distribute the load within the system.  In fact some CASE tools even enable to simulate this aspect of the software. 
• Gives a feel for which classes in the application are going to be complex, which in turn is an indication that may need to draw state chart diagrams for those classes

Activity Diagram

This is used to explore the logic of the following

• A complex operation
• A complex business rule
• A single use case
• Several use cases
• A business process 
• Software processes

Deployment Diagram

Deployment diagrams show the hardware for the system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another.  A deployment model is to:

• Explore the issues involved with installing the system into production.
• Explore the dependencies that your system has with other systems that are currently in, or planned for, the production environment.
• Depict a major deployment configuration of a business application.
• Design the hardware and software configuration of an embedded system. 
• Depict the hardware/network infrastructure of an organization.