Software Architecture Design


Part 1: OO Principles in Practice

Mathias Beck


Architecture Curriculum Overview

■ Shadowing/monitoring/guidance ■ take coachee into meetings ■ additional appraiser ■ monitor and support document ■ provide

On-the-Job Activities /Self-Learning
Ensure participant takes part in Architecture & Design Reviews

Contribute to local architecture guideline Consult and train developers in certain technology & patterns

Close Up: Closure/Feedback Event (0.5 days)

creation and modeling Participate in design reviews, be responsible for SDDs participant with LOB Negotiation Skills (1 day) specific e-learnings and readings Present architecture topic to broader audience ■ include coached in Product Standard Workshop (1 day) eSOA Architecture lecture e-learnings architecture concept Design Patterns in Practice (0.5 d.) discussions Create architecture concept document or SDD Introducing the ■ encourage particiorganizational OO Principles Participate in Architecture Forum pant to contribute Setup of the LOB in Practice (0.5 days) to architecture Participate in PIL meetings(reviews) & networks and wikis become expert for 1 product standard Advanced Presentation Skills (2 days) ■ Identify together with Read PIL pages (process & product standards) participant technology Scalable Client-Server Programming (1 day) of interest and drive Prepared Customer Interaction Basic Principles for Architecture at SAP (2 days) ramp-up of knowledge




Design-Led Innovation e-learnings

Introducing product portfolio of development area, current and target architecture

Architecture Modeling (Blueprint) TAM e-learning


Architecture Definition (1 days)



Design-Led Innovation Workshop (1 day) Technical Architecture Modeling (TAM) (2 days) Kick Off: Responsibilities and Tasks of an SAP Architect (1 day)

Instructor-Led Training (ILT): 13,5 days
© SAP 2008 2007 / Page 2

2. Component Overview 2. 2. Software Design Patterns 3.3. The Singleton Pattern 3. Object-Oriented Programming vs. Object Definition Types Object Elements Object Relations Special Focus Topics 3. Procedural Programming 1. The Factory Pattern 3. Coherent Object Definition 2.2.Agenda 1. OO Programming requires OO Thinking 1. Intro: Object-Oriented Programming 1. The Decorator Pattern © SAP 2009 / Page 3 .4.1.1. 2.

logical sub steps that could completed one step within the program flow so that the overall program can proceed. A software built with procedural programming techniques formed a tree of functions and. two memory types. Procedural Programming focuses on modularization and structuring of functionality. at the very bottom. The major principle of Procedural Programming is the subdivision of an application. Such sub steps. The necessity for procedural programming followed the demand for more complex software built on extremely limited hardware resources. a program.Object Oriented Programming vs. a local memory setup within the function and a global memory lasting during the entire transaction are being used. Procedural Programming separates algorithm/function from memory. or a routine into granular modules. sub-routines or algorithms. if well defined and accessible could be reused in different scenarios. © SAP 2009 / Page 4 . Usually. Procedural Programming Procedural Programming was established in the 1970‟s.

Object Oriented Programming vs. Procedural Programming Object Oriented Programming originated in the late 1970‟s. but in building fine granular components (i. © SAP 2009 / Page 5 . No other object should carry the same task. displayed via a set of attributes and a behavior defined and (partially) exposed via methods. Object-oriented Programming focuses on abstraction and separation of concerns. Objects have a state. each object is a representative of a responsibility. As in real life. These state changes are the result of outbound requests or responses to state changes of other objects. The objects are not defined by a task in a chain. but rather by a responsibility. Thereby the goal is to separate the concerns within the overall solution.e. The Object Orientation Paradigm doesn‟t primarily focus on a program or application. but it flourished only at the end 1980 with the wide spread use of C++ and a progress in hardware resources. objects) that interact together in order to finally accomplish the overall task. During the life time they can change their state.

Procedural Programming Overview over Object Oriented Programming Languages: ABAP ABAP OO non-OO OO © SAP 2009 / Page 6 .Object Oriented Programming vs.

the foundation for service oriented software design was laid. This. the responsibilities and the behavior of the objects will evolve in time or differ once a more specialized view on such an object is in need. was one of the major motivations of Object Orientation – the resemblance with the reality. OO supports such evolution during the software lifecycle with various constructs and patterns. among others. Finally.Object Oriented Programming vs. Procedural Programming Software Objects primarily represent an abstraction of real life objects. the vast number of objects counters the effect again. However. Object Orientation comes with a set of constructs supporting well-defined objects and standardized principles of collaboration among them. © SAP 2009 / Page 7 . as the definition of the required behavior is separated from the actual implementer of the behavior. in modern OO-based software solutions. with the concept of interfaces. As in real life.

the team members need to talk with each other and update (on request) about their status.Object Oriented Programming requires Object Oriented Thinking ! Object Oriented Programming requires a high level of abstraction skills Like in a project organization. some team member do similar or even equal tasks. These „people“ are differentiated by roles and responsibilities and certain rules of collaboration. As in an ideal steady team. every team member is an expert in his/her field. and get an equal (or comparable) result. The requester should be able to request the task in the same way. © SAP 2009 / Page 8 . Nobody does overlapping work. the goal is to identify „people“ that take care of certain tasks in the entire process. These should always be done in the same quality. In order to ensure a good overall result. However.

especially for the area of displaying the inertias of the software systems. To grant a better overview and to support the software development process. © SAP 2009 / Page 9 . not the solution itself gets built.Object Oriented Programming requires Object Oriented Thinking Although the advantages and the potential of object orientation are well perceived by the developer community. but little components that.e.    Over the years the Unified Modeling Language methodology has established itself as the world-wide standard to model software solutions. the standardized notation of software blue-prints/software models is indispensible. Thus. at a later stage will then be assembled. Since OO strongly emphasizes on reuse and model driven development. object orientation comes with certain boundaries:   The demand on the software developer with respect to abstractive thinking is very high The development process is often carried out in an “indirect” manner. SAPs Technical Architecture Modeling methodology includes UML notation. accountable development results come late. i. over-engineering effects can easily occur. especially comprising the object oriented principles.

Such objects mainly represent Entities. CarOwner Driver owns operates has Car has has has Door Wheel Engine Seat © SAP 2009 / Page 10 . Objects resembling real life objects are usually the first choice (and in most cases a good choice to support the comprehensibility of the solution).Coherent Object Definition The most crucial part of Object Oriented development is the object definition.

sequences. Such objects are called Controls or Process Objects. are not always entities representing a physical or legal object in real life. Software objects can also represent process steps. however. activities. CarOwner Driver uses Ride owns operates uses Car has has has has Door Wheel Engine Seat © SAP 2009 / Page 11 .Coherent Object Definition Objects.

object specific „flavors“ is the decision criteria for selecting the corresponding modelling pattern.Coherent Object Definition Driving object modeling and definition further. OpenDoor operates Handle VehicleOwner has has has Wheel has KeyLock Engine has Vehicle has has has KeySystem has Seat Car Truck is a is a Door has uses owns operates uses Ride Driver Frame accesses Window uses Key © SAP 2009 / Page 12 . even sub components of real life objects or sub responsibilities of a process result in additional objects. Depending on their state and special features. To determine absolut common behavior vs. objects can behave differently.

• No instance of an abstract class can be created during run time – a specialization (i. is irrelevant for the accessing object. during the run time each instance is in it„s individual state and can differ in behavior. Each instance has it„s own memory space. A certain part of the class definition is not equipped with an implementation but declared as abstract. an_interface © SAP 2009 / Page 13 . The implementing object„s identity. • The purpose of interfaces is to decouple classes from their constructive structure and focus on an agreed set of methods that can be performed on the implementing object. however. Abstract Class an_abstract_class • An abstract Class is a class that is purposely only partially implemented. • The construct of the Class is defined in the class definition.Component Overview: Object Definition Types Class a_class • A class is the basic form of representing an object • Classes have a static part that is directly active and accessible at program load • Classes have an instance part that is only active as soon as an instance of the class is created. Interface • An interface is a description of the „public“ behavior of a class.e. a class inheriting from the abstract class) must be programmed and only this class can be instanciated • Abstract Classes are used to define a commonality in behavior. However. This behavior is then already implemented and can be reused by the inheriting classes. Thus. • For the definition to come to life it requires a class implementing such interface. interfaces have no implementation and can never be instantiated. the algorithms and functions to make the class fulfill its responsibility are defined in the class implementation.

but right away.They can be of contrete type or references to other objects. Static elements exist only once. but acts upon the occurence of the respective event. protected or private. Events propagate a state change within and beyond the object boundaries Visibility Elements can be public. . They have a well defined signature and can be called within or (depending on the Visibility) outside the object boundary Methods acting as an Event Handler cannot be called directly. Instance elements exist per Instance and differ in state and behavior depending on the overall state of the instance A class composes basically of State and Behavior elements which vary in Scope and Visibility: State Attributes define the state of the object. Public elements are accessible from within and outside the class Protected elements are only accessible within the class and inheriting subclasses Private elements are only accessible within the class © SAP 2009 / Page 14 Behavior The behavior is defined by Methods. The access is not depending on an instance.Component Overview: Object Elements Scope Elements can either exist statically or per instance.

• Inheritance illustrates that Object1 is taking over the definition and implementation of Object2. Object1 cannot exist without Object2. Thus. Aggregation Object1 Object2 • Aggregation illustrates that part of Object1„s state is defined by referencing to Object2. Composition Object1 Object2 • Composition illustrates an aggregation in which Object2 alone cannot exist but depends on the existence of Object1. if permitted by Object2. Object1 Instanciation • Instanciation illustrates that Object1 takes responsibility of creating instances of Object2. alter the behavior of methods or alter the object state. © SAP 2009 / Page 15 . Object1 can add additionally elements. Object 2 is usually a class within Object 1. and/or. Inheritance Object1 Interface1 Realization Object2 • Realization illustrates that Object1 provides an implementation for all the methods defined in Interface1.Component Overview: Object Relations Object1 Object2 Association Object1 Object2 • Association illustrates that Object1 needs to access Object2 (in certain constellations) in order to completely fulfill its responsibilities.

1 KeyLock 1 0.* uses uses <<control>> Ride Driver © SAP 2009 / Page 16 .* Car Truck Wheel * Vehicle Door 1....* Engine 1 Seat 1.Component Overview: Object Relations (applied) <<control>> OpenDoor Person operates Handle VehicleOwner 1 operates Frame 1 accesses Window uses Key 1..* KeySystem 0..

but (in most OO languages) only inherit from one class  Aside from the set of methods defined by the interface.  A class can implement several interfaces. However. but can be used as a unified access to classes both force the implementer of certain behavior to oblige to certain agreed methods and signatures.  An abstract classes pre-defines behavior. not implementations © SAP 2009 / Page 17 . ! Standard Rule: Program against interfaces. also no common behavior can be placed commonly at the interface. This can easily be a limitation. ! The more similar the objects the harder to make the right choice Interface3 ab stractClass_1 ab stractClass_2 myClass In order to choose the right construct.Component Overview: Special Focus: Interface vs. the class can take all possible shapes and change during it‟s life cycle.  An interface defines a common set of methods and their signatures. Abstract Class Interface1 Interface & abstract class are constructs with a lot of similarities:   myClass  Interface2 both contain a definition without actual implementation both cannot exist at run time. is imperative to understand the differences:  Since interfaces do not come with any implementation no predefined behavior can be forced on the implementer.

Component Overview: Special Focus: Curse of Inheritance Animal Mammal Bird Insect Cat Bat Eagle Chicken Duck Goose Peacock Ant Catepillar Bee Where to place that behavior? How to avoid duplicate definition? How to avoid duplicate implementation? © SAP 2009 / Page 18 .

Component Overview: Special Focus: Curse of Inheritance ..... but then again. but most insects and even some mammals can fly … . do I have to override for all objects that can„t fly? © SAP 2009 / Page 19 .

in such a way that you can use this solution a million times over. without ever doing it the same way twice. Christopher Alexander “ © SAP 2009 / Page 20 .Software Design Patterns „ Each pattern describes a problem which occurs over and over again in our environment. and then describes the core of the solution to that problem.

but as seen earlier. also with risks.Software Design Patterns Object Orientated Programming comes with great potentials. The main goals are to:  Avoid classical pits and traps  Maximize reusability  Minimize the need for modification  Unify the various implementation  Increase understanding  Decrease development risk © SAP 2009 / Page 21 . a selection of patterns and idioms have evolved reducing the risk of driving the software in deadend scenarios or increasing complexities. Over the years.

Software Design Patterns 1: The Singleton Pattern – An Example Find a pattern to enable global access from all requesting parties to one and the same object instance. © SAP 2009 / Page 22 .

In such a case. the methods can be redefined. So. Also.   “ Be best prepared for future changes Keep track of my class instances The primary advantage of Singleton is that the class definition can be done with instance elements.Software Design Patterns 1: The Singleton Pattern „ A Singleton is a class that ensures that exactly one instance of it can exist during run time. if there is a later need for polymorphism. the singleton can then be transferred into a multi instance construct with minimal impact on the code base. an additional criteria might be needed at the factory method (get_instance( ) ). This one instance can be globally accessed. © SAP 2009 / Page 23 . The singleton pattern covers 2 problems of software development with classes.

Have a centrally accessible component in order to retrieve objects of a specific type  Keep track of my class instances Factories are usually static objects whose main public method is the factory method itself. © SAP 2009 / Page 24 . By separating instance creator and implementing classes. changes/additions in the inheritance tree can be carried out without impacting existing implementations. The factory pattern is primarily fulfilling 3 tasks:   “ Conceal the decision which concrete class will be instantiated based on the requested criteria.Software Design Patterns 2: The Factory Pattern „ A Factory is a class that takes responsibility for the instantiation (and additonally the instance management) of objects fulfilling a common definition (abstract class / interface).

Software Design Patterns 2: The Factory Pattern – An Example This Factory only provides the right Product This Factory provides Orders and keeps track of them. © SAP 2009 / Page 25 .

individual) method definitions and implementations.e. © SAP 2009 / Page 26 . “ Since Decorators are as well part of the inheritance tree. a decorator class wraps itself around the respective objects and simulates them completely except for the additional “decoration”.Software Design Patterns 3: The Decorator Pattern „ A Decorator is a class that can add a certain behavior to multiple classes within an inheritance without following the existing hierarchy. and in order to avoid duplicate (i. Instead of defining and redefining from one level to the next. they can be wrapped by other decorators. Decorator classes solve the problem that multiple classes within an inheritance tree share a common behavior which does contradict the original hierarchy.

Software Design Patterns 3: The Decorator Pattern – An Example © SAP 2009 / Page 27 .

Q&A © SAP 2007 / Page 28 .

Thank you! © SAP 2009 / Page 29 .

Sign up to vote on this title
UsefulNot useful