Object-Oriented Analysis & Design (OAD)

OAD Introduction
Alexander Felfernig Institute for Software Technology Inffeldgasse 16b/2

Goals
Introduction to OAD Start: 16.15h (16.00h c.t.) Course exams: altogether >= 50% (but also the individual exams >= 50%)

-2-

Software Systems
model part of the real world are often large and complex must be maintainable must be highly reliable must be user-friendly must be efficient

to build high-quality systems we need

a process with clearly defined activities (e.g., Unified Process) techniques for supporting the activities (e.g., UML) tools for generating the products (e.g., Visual Paradigm)
-3-

Successful Software Development means

understanding the requirements prioritizing the requirements tracing the changes knowing the risks assuring the quality of artifacts Approximately 40% of the total project budget is related to rework costs triggered by low-quality requirement definitions! [1]

-4-

Software Process
goal: producing high-quality products in a disciplined process described by a set of activities that transform requirements into software requirements state
services to be provided: functional requirements non-functional requirements (e.g., response times, usability, etc.)

challenge: requirements are incomplete, not understandable, unstructured, inconsistent first activity: OOA (Object Oriented Analysis)
-5-

Why OOA?
understanding of what we want to develop what? vs. how? (analysis vs. design) scenario vs. integrated state model object model vs. relational algebra

-6-

Requirements Engineering
main activity in OOA requirements document: relevant requirements for the software system
requirements capture: abstraction classification: clustering & prioritization validation/verification: right requirements? / requirements right? feasibility: resources available?

late error discovery triggers high costs! next phase: OOD (Object Oriented Design)
-7-

Why OOD?
understanding of how we will develop the software integrated state model vs. implementation OCL constraints vs. implementation relational algebra vs. database
-8-

Design
logical design
partitioning of requirements to components how do components interact?

detailed design
each component is designed individually how does a component solve its tasks?

-9-

Effective Teams

For details see [3]

-10-

Roles in Team
Analysts (A): eliciting and investigating requirements (relationship with customer) Developers (D): designing and implementing software Managers (M): managing and configuring the software engineering process Testers (T): testing the software General (G): further activities if needed
-11-

Enterprise Applications
support typical problem solving scenarios in enterprises (e.g., online selling applications)
in contrast to technical & scientific applications in contrast to the system programming level (operating systems, hardware, computer networks, etc.)

are data-intensive
high data volumes (e.g., millions of customers and items) not (!) computational intensive (in contrast to technical & scientific applications )

are Input/Output (I/O)-intensive

major role of data/information collection and retrieval no complex underlying algorithms
-12-

Enterprise Applications
are transaction oriented
information/data used in a distributed environment (e.g., www.amazon.com) for instance, essential for functionalities related to booking, payment, etc.

are end user oriented

applicable for users with different educational background (usability aspects, etc.) optimal support for working processes crucial (e.g., recommendations) flexibility/adaptability important (e.g., sales and marketing rules regarding the recommended items have to be continuously adapted)
-13-

Types of E-Applications
operative
day-to-day business, e.g., bookkeeping, order management, material management, recommendation, etc. administration, lower-level management

tactic
key metrics, statistics, e.g., # of new customers per period, monthly turnover, etc. upper-level management

strategic
planning, decision support, e.g., market forecasting high-level management

-14-

References
1. D. Leffingwell. Calculating the return on investment from more effective requirements management. American Programmer, 10(4):1316, 1997. 2. D. Yang, D. Wu, S. Koolmanojwong, A. Brown, and B. Boehm. WikiWinWin: A Wiki Based System for Collaborative Requirements Negotiation, HICCS, p. 24, 2008. 3. E. Demirrs, G. Sarmasik, and O. Demirrs. The Role of Teamwork in Software Development: Microsoft Case Study, 23rd EUROMICRO Conference New Frontiers of Information Technology, IEEE, pp. 129-133, 1997.
-15-