Object Oriented SAD

ITOOA3
 Disclaimer

Please note that the content made available on myLMS may deviate
slightly from what is covered in lecturer-led sessions. However, the
material on myLMS, along with prescribed textbooks and any other
designated learning resources, constitutes the compulsory content
students are expected to consult and prepare for assessments.
 What will be covered in the rest of today’s session?

What will be covered in the lecture-led session:

• Understand the validation & verification of the analysis models.

• Understand transition from analysis to design
• Understand the use of factoring, partitions, and layers.
• Be able to create package diagram.
• Be able to create an alternative matrix.
 Introduction
• The purpose of analysis is to figure out what the business needs are. The
purpose of design is to decide how to build the system. The major activity that
takes place during design is evolving the set of analysis representations into
design representations.
• Design also includes activities such as designing the user interface, system
inputs, and system outputs, which involve the ways that the user interacts with
the system.
• Finally, physical architecture decisions are made regarding the hardware and
software that will be purchased to support the new system and the way that the
processing of the system will be organized.
 Verifying & Validating the Analysis Models

Before we evolve our analysis representations into design representations, we need

to verify and validate the current set of analysis models to ensure that they faithfully
represent the problem domain under consideration.
 Evolving the Analysis Models into Design Models

• The primary purpose of the design models is to increase the likelihood of

successfully delivering a system that implements the functional requirements in a
manner that is affordable and easily maintainable. Therefore, in systems design, we
address both the functional and nonfunctional requirements.
• We must review the analysis models again. However, this time we begin looking at
the models of the problem domain through a design lens. In this step, we make
modifications to the problem domain models that will enhance the efficiency and
effectiveness of the evolving system.
• We introduce factoring, partitions and collaborations, and layers as a way to evolve
problem domain-oriented analysis models into optimal solution domain-oriented
design models.
 Factoring
• Factoring is the process of separating out a module into a stand-alone module. The new
module can be a new class or a new method.
• Abstraction and refinement are two processes closely related to factoring.
• Abstraction deals with the creation of a higher-level idea from a set of ideas. Identifying
the Employee class is an example of abstracting from a set of lower classes to a higher
one.
• The refinement process is the opposite of the abstraction process.
 Partitions & Collaborations
• A partition is the object-oriented equivalent of a subsystem, where a subsystem is a
decomposition of a larger system into its component systems (e.g., an accounting
information system could be functionally decomposed into an accounts-payable
system, an accounts-receivable system, a payroll system, etc.).
• An easy approach to model partitions and collaborations include packages and package
diagrams.
• In cases where classes are supporting multiple use cases, the collaborations should be
merged.
• One of the easiest techniques to identify the classes that could be grouped to form a
collaboration is through the use of cluster analysis or multiple dimensional scaling.
These statistical techniques enable the team to objectively group classes together
based on their affinity for each other. The affinity can be based on semantic
relationships, different types of messages being sent between them (e.g., create, read,
update, delete, or execute), or some weighted combination of both.
• The general rule is the more messages sent between objects, the more likely the objects
belong in the same partition.
• Another useful approach to identifying potential partitions is to model each collaboration
between objects in terms of clients, servers, and contracts. A client is an instance of a class
that sends a message to an instance of another class for a method to be executed; a server
is the instance of a class that receives the message; and a contract is the specification that
formalizes the interactions between the client and server.
• The primary purpose of identifying collaborations and partitions is to determine which
classes should be grouped together in design.
 Layers
• We have focused only on one layer in the evolving software architecture:
the problem domain layer. There should be a layer for each of the
different elements of the system environment (e.g., data management,
user interface, physical architecture).
• Like partitions and collaborations, layers also can be portrayed using
packages and package diagrams.
 Packages & Package diagrams
• In UML, collaborations, partitions, and layers can be represented by a higher-level
construct: a package.
• A package serves the same purpose as a folder on your computer.
• A package diagram: a diagram composed only of packages.
• Packages represent groupings of classes. Therefore, aggregation and association
relationships are possible.
• A dependency relationship is portrayed by a dashed arrow. It is possible that a change
in one package could cause a change to be required in another package.
 Guidelines for Creating Package Diagrams
• Use package diagrams to logically organize designs. Specifically, use packages to group
classes together when there is an inheritance, aggregation, or composition relationship
between them or when the classes form a collaboration.
• In some cases, inheritance, aggregation, or association relationships exist between
packages. In those cases, for readability purposes, try to support inheritance
relationships vertically, with the package containing the superclass being placed above
the package containing the subclass. Use horizontal placement to support aggregation
and association relationships, with the packages being placed side by side.
• When a dependency relationship exists on a diagram, it implies that there is at least
one semantic relationship between elements of the two packages. The direction of the
dependency is typically from the subclass to the superclass, from the whole to the part,
and with contracts, from the client to the server. In other words, a subclass is
dependent on the existence of a superclass, a whole is dependent upon its parts
existing, and a client can’t send a message to a non-existent server.
• When using packages to group use cases together, be sure to include the
actors and the associations that they have with the use cases grouped in
the package. This will allow the diagram’s user to better understand the
context of the diagram.
• Give each package a simple, but descriptive name to provide the package
diagram user with enough information to understand what the package
encapsulates. Otherwise, the user will have to drill-down or open up the
package to understand the package’s purpose.
• Be sure that packages are cohesive. For a package to be cohesive, the
classes contained in the package, in some sense, belong together. A simple,
but not perfect, rule to follow when grouping classes together in a package
is that the more the classes depend on each other, the more likely they
belong together in a package.
Creating Package Diagrams
1. Set context
2. Cluster classes
3. Create packages
4. Identify dependencies
5. Lay out and draw diagram
 Verifying & Validating Package Diagrams
Like all the previous models, package diagrams need to be verified and
validated. In this case, the package diagrams were derived primarily from
the class diagram, the communications diagrams, and the CRUDE matrix.
Only two areas need to be reviewed.
• First, the identified packages must make sense from a problem domain
point of view.
• Second, all dependency relationships must be based on message-
sending relationships on the communications diagram, cell entries in
the CRUDE matrix, and associations on the class diagram.
Design Criteria
When considering the design of an object‐oriented system, a
set of criteria exists that can be used to determine whether
the design is a good one or a bad one. According to Coad and
Yourdon, “A good design is one that balances trade‐offs to
minimize the total cost of the system over its entire lifetime.”
These criteria include coupling, cohesion, and connascence.
Coupling
Coupling refers to how interdependent or interrelated the modules
(classes, objects and methods) are in a system. The higher the
interdependency, the more likely changes in part of a design can cause
changes to be required in other parts of the design. For object-oriented
systems, Coad and Yourdon identified two types of coupling to consider:
interaction and inheritance.
1. Interaction coupling deals with the coupling among methods and
objects through message passing.
2. Inheritance coupling, as its name implies, deals with how tightly
coupled the classes are in an inheritance hierarchy.
Examples of Interaction Coupling
Cohesion
Cohesion refers to how single-minded a module (class, object or
method) is within a system. Three general types of cohesion:
• Method cohesion – Methods should do one and only one thing.
• Class cohesion – A class should represent only one thing, such as an
employee, a department, or an order.
• Generalisation/specialisation cohesion – addresses the sensibility of
the inheritance hierarchy. How are the classes in the inheritance
hierarchy related?
Connascence
Connascence generalises the idea of cohesion and coupling and it combines them with the
arguments for encapsulation. To accomplish this, three levels of encapsulation have been
identifying.
Level-0 encapsulation refers to the amount of encapsulation realised in an individual line of
code,
level-1 encapsulation is the level of encapsulation attained by combining lines of code into a
method and
level-2 encapsulation is achieved by creating classes that contain both methods and attributes.
Method cohesion and interaction coupling addresses primarily level-1 encapsulation. Class
cohesion, generalisation/specialisation cohesion and inheritance coupling address only level-2
encapsulation. Connascence, as a generalization of cohesion and coupling, addresses both
level-1 and level-2 encapsulation.
Design strategies
• Custom development
• Package software
• Outsourcing
Selecting a Design Strategy
• Business need
• In-house experience
• Project skills
• Project management
• Time frame
Case
Study Susan, president of MOTO, Inc., a human resources management firm, is reflecting on the client
management software system her organization purchased four years ago. At that time, the firm had just
gone through a major growth spurt, and the mixture of automated and manual procedures that had been
used to manage client accounts became unwieldy. Susan and Nancy, her IS department head, researched
and selected the package that is currently used. Susan had heard about the software at a professional
conference she attended, and, at least initially, it worked fairly well for the firm. Some of their procedures
had to change to fit the package, but they expected that and were prepared for it. Since that time, MOTO,
Inc., has continued to grow, not only through an expansion of the client base but also through the acquisition
of several smaller employment-related businesses. MOTO, Inc., is a much different business than it was four
years ago. Along with expanding to offer more diversified human software vendors also offer products that
may be suitable. Some of these vendors did not exist when the purchase was made four years ago. Susan is
also considering Nancy’s suggestion that the IS department develop a custom soft ware application.

Source: Dennis, A., Tegarden, D. and Wixom, B. 2021. Systems Analysis and Design: An Object-Oriented Approach with UML.
6th edition. USA: Wiley.
Problem-Based Learning
From Case Study…

Outline the issues that Susan should consider that would

support the development of a custom software application
in-house.

Outline the issues that Susan should consider that would

support the purchase of a software package.

Within the context of a systems-development project, when

should the decision of make-versus-buy be made? How
should Susan proceed? Explain your answer.
Discussion
• What are some of the problems with using a packaged
software approach to build a new system? How can these
problems be addressed?
• Why do companies invest in ERP systems?
• When is outsourcing considered a good design strategy?
When is it not appropriate?
• How are the alternative matrix and feasibility analysis
related?
• What is an RFP? How is it different from an RFI?
Discussion
• Explain the primary difference between an analysis model &
a design model.
• What is meant by balancing the model?
• What are the interrelationships among the functional,
structural, and behavioral models that need to be tested.
• What are the five steps for identifying packages and creating
package diagrams.
Activity

Suppose you are leading a project that will

implement a new course enrollment system for your
university. You are thinking about either using a
packaged course enrollment application or
outsourcing the job to an external consultant.

Task: Create an outline for an RFP to which

interested vendors and consultants could respond.
 Activity
Suppose you and your friends are starting a small
business painting houses in the summertime. You
need to buy a software package that handles the
financial transactions of the business.

Task: Create an alternative matrix that compares

three packaged systems (e.g., Quicken, MS
Money, Quickbooks). Which alternative appears to
be the best choice? Motivate your answer.
 What Happens Next?

Week 7
• Read Chapter 8 – Class and Method Design
• Complete the myLMS activities
Bibliography
Dennis, A., Tegarden, D. & Wixom, B. 2021. Systems Analysis and Design: An Object-Oriented Approach with UML. 6th ed.
USA: Wiley.