CIS510 Discussion Post Reply

CIS510 discussion post responses.

Respond to the colleagues posts in one of the following ways:

· From a strength's perspective, critique your colleague's approach to modeling a use case that differs from an object-oriented approach. Provide support for your critique.

· Critique your colleague's strategy for there scenario.

OT’s post states the following:Top of Form

Traditional Approach vs. OO Approach

Traditional use cases model a system’s procedural structure, whereas OOA use cases model a system’s logical structure. OOA identifies the system’s classes, and the relationships and interactions between the objects, including how data flows between them. Additionally, OOA use cases enable us to model complexity (Wazlawick, 2013) within the system and data encapsulation (2013).

Using Traditional vs. OOA

I use traditional use cases when working with users to document and validate their business processes. Most users don’t understand OOA (nor should they need to). If I were to use OOA models at this point, I would spend too much time explaining the model rather than listening to the users explain their processes and pain points. Such misalignment leads to frustrated and discouraged uses, which puts the project at risk.

However, after we've validated the interactions and flows, I create OOA use cases from the traditional use cases. This activity accomplishes several things:

· it ensures that the team has identified all relevant data associated with the business;

· it helps identify opportunities to improve the system’s logical structure; and

· it ensures that the team shares common understanding of the requirements.

Reference

Wazlawick, R.S. (2013). Object-Oriented Analysis and Design for Information Systems, Modeling with UML, OCL, and IFML. Elsevier Editora Ltda. Retrieved from http://dahlan.unimal.ac.id/files/ebooks2/2014%20Object-Oriented%20Analysis%20and%20Design%20for%20Information%20Systems.pdf

GO’s Post states the following

The traditional approach is more sequential. The system is seen as a collection of processes that take in data, manipulate data, and produce results. In the traditional approach, there is a greater focus on system processes. In opposite of that, the object-oriented approach focuses on parts of the system and how they interplay with each other and with users. (Satzinger,2016)

An example of the traditional approach is data flow diagrams (DFD). Charts are created that display elements like data flows and stores, external agents, and system processes in one graphical display. In short, the system is represented in simple graphics that make it easier to understand how it takes in, stores, processes, and outputs data. (Satzinger,2016)

One reason to use DFD’s is to shorten meeting times by illustrating system processes in a simple fashion. Object-oriented approaches handle relationships of systems but not how the systems themselves behave in detail.

Long meetings can slow down the process of making the necessary calls to run a business. Longer meetings can also allow for disputes among staff. (“on the agenda:shorter, better meetings,” 1994) With simple diagrams, it is easier to illustrate a point and cut down on the confusion and misinterpretations that can come from complex graphics or long descriptions.

Resources:

On the agenda: Shorter, better meetings. (1994). Secretary, 54(9), 5. Retrieved from https://search.ebscohost.com/login.aspx?direct=true&db=bth&AN=9412064071&site=eds-live&scope=site

Satzinger, J. (2016) Systems Analysis and Design in a Changing World, 7e. [Strayer University Bookshelf]. Retrieved from https://strayer.vitalsource.com/#/books/9781305465268