Sunday, July 20, 2008

Object Oriented Architecture Modeling

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
o Managerial basis for cost estimation & process mgmt
o Reuse
o Consistency and dependency analysis
o 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.:
o Written documents
paragraph, the nouns, pronouns, noun phrases, adjectives, adjectival phrases, adverbs, and adverbial phrases will suggest candidate objects.
o 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.

No comments: