Question

description of Object Oriented Analysis using UML for POS

Answer 1

To define object-oriented analysis we must first define what we mean by an object. The definition of an object, according to most dictionaries, is “a tangible, material thing.” Drilling down a bit more to the realm of computer science, an object can be most anything in a programmatic sense, from a variable or data model to a function, class, or method. Moving even deeper into the realm of object-oriented programming, an object is an instance of a thing that typically represents a real world object and has all the same types of characteristics (properties), behaviors (methods), and states (data). When discussing OOADconcepts, an object most closely resembles the object-oriented programmingversion of an object, in that it is a representation of a real world object with behaviors, characteristics, and states.

With that out of the way, we can define object-oriented analysis (OOA). In short, OOA is an iterative stage of analysis, which takes place during the software development life cycle, that aims to model the functional requirements of the software while remaining completely independent of any potential implementationrequirements. To accomplish this task via OOAD practices, an object-oriented analysis will focus everything through the lens of objects. This forces OOA to combine all behaviors, characteristics, and states together into one analysis process, rather than splitting them up into separate stages, as many other methodologies would do.

To accomplish this goal, a typical OOA phase consists of five stages:

Find and define the objects.

Organize the objects.

Describe how the objects interact with one another.

Define the external behavior of the objects.

Define the internal behavior of the objects.

For example, a typical implementation of OOA is to create an object model for an application. The object modelmight describe the names, relationships, behaviors, and characteristics of each object in the system. With this information established for each object, the design process that follows is much simpler.

Disadvantages of Object-Oriented Analysis and Design

Ill-Suited to Procedural Applications: Given the object-oriented nature of OOAD, it is quite difficult (although not impossible) to practice OOADtechniques within a procedural programming language, or often to apply the techniques to non-object business logic. Whereas procedural applications are often logically bound by concepts of scope and modularity, object-oriented applications, of course, emphasize objects that simulate the real world, making OOAD methods ill-suited for procedural languages and applications.

Too Complex for Simple Applications: While arguably not a disadvantage that is applicable to all projects, it’s certainly the case that OOAD practices are generally not ideal for simpler projects. Many developers have their own personal hard and fast rules to help when deciding whether a project should be procedural or object-oriented, but in most cases, the more basic the needs of the application, the more likely a less-structured, procedural approach is the best fit. As always, we must always use our own best judgment.

uml for point of scale:_

usecase daugram;

System generates sales report Reorder depleted inventory Manager Supplier chetk inventory Update inventory check out nventory syster scan item cashier calculate total tax payment Customer by cheque by debitby cash by credit