Chapter 2. Software architecture Architecture style OOSE review Software architecture Layered architecture
Architecture style • System that share a similar high-level structure are said to have a similar architecture style • Approaching reuse without understanding architecture style is like starting to construct a building without knowing if it will be a skyscraper or a garage • Software of the same architecture style can be reused easier than those of different architecture styles
Architecture style • An architecture style is defined by the type of constructs that can be reused to engineer a system • Definition: the architecture style of a system is the denotation of the modeling languages used when modeling that system • Example: UML (which is a modeling language) defines an architecture style
OOSE review • Software reuse in the text book is closely related to OOSE of I. Jacobson. Therefore, we review the OOSE in the following slides • Jacobson’s OOSE technique includes the following phases: analysis, construction, and testing
Analysis phase • Purposes of analysis: • To capture requirements • To represent requirements in models • Products of the analysis phase • Requirement model: to describe system functionality • Analysis model: to describe objects that accomplish system functionality
Analysis phase – requirement model • The requirement model describes system functionality • The model is composed of use case diagram, interface description, and domain objects
Analysis phase – requirement model • The use case diagram is composed of: • Actors • Use cases • Relationships among use cases • The interface description describe how the user can use the system. • The domain objects are objects identified in the problem domain
Analysis phase – analysis model • The analysis model is a robust model to adapt to change, which uses interface objects, entity objects, and control objects to describe system functionality • Creating analysis model corresponding to assigning functionality of use cases to objects (see figure in the next slide)
Analysis phase – analysis model • The following functionality should be allocated to interface objects • Those present information to actors or request information from actors • Those change when actors’ behavior change • Those depend on a particular interface type, e.g., changing card types results in changing the input device of the ATM machine
Analysis phase – analysis model • Entity objects model the information that a system will handle over a long time • Possible entity objects: • Those mapped to problem domain objects • The information that should be remembered • Operations of entity objects can be identified from use case functionality
Analysis phase – analysis model • Control objects are used to improve robustness of the analysis model • Behaviors that are sensitive to change can be allocated to control objects, e.g., workflow in a MIS • Behaviors that are not suitable for other objects can also be allocated to control objects
Analysis phase – analysis model • Use cases can be described by analysis objects as shown in the figure of the next slide
Construction phase • Two models are developed in the construction phase, namely the design model and the implementation model • The implementation model is the program code
Construction phase - design model • The design model is developed based on the analysis model; implementation environment is taken into consideration • The considered environment factors includes platform, language, DBMS, constraints, reusable components, libraries, and so on
Construction phase -design model • Design objects in the design model are different from analysis objects • The design model also models design object interactions, design object interface, and design object semantics (i.e., algorithms of design objects’ operations)
Construction phase - design model • In the design process, the analysis model is first transferred into the initial design model (figures in the next slides). Then, implementation environment factors are incorporated. For example, the “extend” relationship should be replaced by “invoke” relationship because no OO programming language supports the former
Take a deep breath and be ready for the other presentations
Software architecture • Software architecture defines system structures, interfaces, and interaction patterns • Example architectures: see the next slides
object object object object Object-oriented architecture
Software architecture • Definition: software architecture defines the static organization of software into subsystems interconnected through interfaces and defines at a significant level how nodes (sites) executing those software subsystems interact with each other.
Software architecture • A good architecture facilitates controlling software complexity and allows large organizations to work on parts in parallel • An architecture should be robust. That is, it can be adapted to change (or change should be predicted) • A good architecture acts as a guide to which components should be reused during the development of application systems
Layered architecture • Before discussing layered architecture, we give some definitions below: • Software workproduct: a product or sub-product produced in a software engineering phase. For example, a subsystem of a design document can be regarded as a software workproduct • Asset: high-quality software workproductsthat can be reused
Layered architecture • Some definitions (cont.) • Component: an element of a development model (i.e., software) that is loosely coupled and promised to be reusable. Under this definition, all software workproducts are potentially components or sources of components. • Component system: a set of related components that accomplish some function larger than that accomplished by a single component. In other words, a component system is a larger component composed of components or component systems. Component systems thus facilitate large-scale reuse.
Layered architecture • Some definitions (cont.) • Facade: an aspect of a component system a reuser needs to know when he/she reuses the component system. A facade exports only those a reuser needed and encapsulates other details of a component system. (Take facade in mind, it is the primary concept in the text book).
Layered architecture • The sense behind the layered architecture: • Application systems can be built from component systems • Component systems may in turn be built from components in lower layers • The sense above results in a layered system defined by a layered architecture (see the figure in the next slide)
Middleware System software
Layered architecture • Definition: a layered architecture is a software architecture that organizes software in layers. Each layer is built on top of another more general layer. A layer can loosely be defined as a set of (sub)systems with the same degree of generality. Upper layers are more application specific and lower are more general
Layered architecture • The number in a layered architecture may be varied from situation to situation. For example, the business-specific layer (see the figure in the slide before the previous slide) can be composed of more than one layer
Layered architecture • The topmost layer (application systems layer) contains application systems offering coherent set of use cases to end users. Some application systems may possess more than one version (or variant) • The business-specific layer contains a number of component systems specific to the type of business (i.e., specific to a problem domain). Such component systems include use case and object components. This layer is the focus of my presentation.
Layered architecture • The middleware layer offers components systems providing utility classes and platform-independent services such as distributed object computing in heterogeneous environments. Examples in this layer are GUI builders, DBMS interfaces, CORBA broker, and so on. This layer is the focus of your presentation
Layered architecture • The system software layer contains the software for the computing and networking infrastructure, such as OS, interfaces to specific hardware (i.e., drivers), sockets, and so on. Some components in this layer are hardware (or platform) dependent