Fundamentals of Object Oriented Modeling

Abstraction Abstraction is about: Looking information's that are relevant at that time. Hiding details so as not to confuse the bigger picture. Abstraction is the fundamental principle of modeling.

Modeling When we model, we create a number of views of the system being described Each view is needed for a full understanding of the system. Each view has information that is unique to that view Each view has information that appears in other views The information that is common between views is consistent

Model Organization All model syntaxes provide a number of model elements which can appear on one or more diagram types. Structured Analysis Is a method of analysis and converting business requirements in to Specification In structured analysis there are three orthogonal views: The functional view, made up of data flow diagrams, It is the primary view of the system. It defines what is done, the flow of data between things that are done and provides the primary structure of the solution. The data view, made up of entity relationship diagrams, Is a record of what is in the system, or what is outside the system that is being monitored The dynamic view, made up of state transition diagrams, Defines when things happen and the conditions under which they happen.

Encapsulation of Hardware The concept of encapsulation of data and functionality that belongs together is something which the hardware industry has been doing for a long time. Elementary Boolean functions are encapsulated together with bits and bytes of data in registers on chips. Chips are encapsulated together on circuit boards. Circuit boards are made to work together in various system boxes that make up the computer. Computers are made to work together across networks. Hardware design, therefore, is totally object oriented at every level and is, as a result, maximally re-useable, extensible and maintainable; in a single word: flexible. Encapsulation of Software Functionality and data is encapsulated in objects. Objects are encapsulated in components. Components are encapsulated into systems.

Unified Modeling Language

UML What it is Unified Modeling Language Graphical representation of different aspects of a Software System. UML offers a standard way of writing Conceptual things such as, Business Process, System Functions, Programming Language Statements, Database Schemas, Reusable Software components.

UML diagram Types There are different types of UML diagram, Use case diagrams. Class diagrams. Interaction diagrams. State diagrams. Activity diagrams. Component diagrams. Deployment diagrams.

UML Diagrams Use Case Diagrams Describe the functional behavior of the system as seen by the user. Describe the properties of the objects in the system and their relationships. These include collaboration and sequence diagrams, This shows how objects interact to fulfill the functionality of the use case. Class Diagrams Interaction Diagrams

State Diagrams To describe the behavior of a system model the workflow behind the system being designed Show the types of components, their interfaces and dependencies in the software architecture that is the solution to the application being developed. Deployment Diagrams Show actual computing nodes, their communication relationships and the processes or components that run on them. Use Case Diagrams Use Case represents functionality of the system Nodes of the graph are actors and Use cases A system may be defined as the sum of its use cases Relationships among use cases and actors are described using Links of graph Activity Diagrams Component Diagrams

Use case relationships Association Include Extend Generalization

Association Relationship - Relationship between an actor and the use case An actor may be associated with more than one use case and vice versa Include Relationship - Allows a use case to access a set of behaviors defined in another use case. It is a mechanism for capturing and representing common behaviors used by multiple use cases Extends Relationship - Allows a use case to be extended with additional behavior and variations

A use case can have many extension points Extending use case may add additional behavior at extension points Generalization Relationship Describes a variation on normal behavior Is the only relationship allowed among actors. Class Diagram Describes Objects types in system and their static relationships Attributes and operations of a class Constraints that apply to the way objects are connected

Class Diagram Relationship Association Generalization Aggregation Composition

Types of Relationships Association Represents relationships between instances of class Each association has two association ends Each end o Is attached to one of the classes in the association o Can be given a role name o Supports multiplicity (indicating number of objects in a given relationship) Generalization Is associated with in programming languages The subclass inherits all the methods and fields of the super class and may override inherited methods

Aggregation inheritance Denotes a whole/part of a hierarchy Implies the ability to navigate from the aggregate to its parts The part object may belong to only one whole The parts are usually expected to exist with whole Deletion of the whole is considered to cascade the parts

Composition

Sequence Diagram Is an Interaction Diagram Represents objects horizontally across top of the diagram A dashed vertical line is drawn below each object Messages denote events, are shown horizontally Ordering is indicated by vertical position Displays first message at top and last message at bottom of the diagram

Collaboration Diagram Describes linked objects Uses the layout to overlay packages or other information Used to design procedures and show navigation

State Diagram Describes behavior of a system Shows all possible states of a particular object in several use cases

Activity Diagram Describes the sequencing of activities, with support for both conditional and parallel behavior An activity is a process like execution of software routine

Component Diagrams Component Diagrams show the types of software components in the system, their interfaces and dependencies. Deployment Diagram Deployment diagram show the computing nodes in the system, their communication links, the components that run on them and their dependencies.

Software Development Process

Business Process Modeling A Business Model may be created to better understand the business, either for the purpose of improving the business itself, or as a way of discovering requirements for a computer system. Process Modeling Notation A Business Process Model typically defines the following elements: The Goal or Reason for the Process. Specific inputs Specific Outputs Resource Consumed Activities that are performed in some order and Events that driven the process.

System Requirement Definition Implementation constraints are modeled separately from the use case model. The logical functional requirements of systems are modeled using use cases and use case descriptions. These give a detailed textual description of the use case flow and other logical constraints. Using use cases for the logical requirements has a number of advantages: o It is an outside-in view and easily understood by non-technical people. o It is more likely to be complete than a classical functionally decomposed specification. o It directly maps into, and is traceable to, acceptance tests, user documentation and the analysis and design models System Analysis Model The System Analysis Model is made up of class diagrams, sequence or collaboration diagrams and state chart diagrams. This model: o Defines what the system does not how it does it. o Defines logical requirements in more detail than the use case model, rather than a physical solution to the requirements. o Leaves out all technology detail, including system topology Screen Prototyping Screen prototyping can be used as another useful way of getting information from the users. When it is integrated into a UML model: o The flow of the screen is made consistent with the flow of the use case and the interaction model. o The data entered and displayed on the screen is made consistent with the object model. o The functionality of the screen is made consistent with the interaction and object models.