Unit I SOFTWARE MODELING AND DESIGN By Prof

Unit I SOFTWARE MODELING AND DESIGN By Prof. R. B. Rathod

Introduction to Software Design (Cont…) • Input of software design: Requirement analysis models and specification document • Output of software Design models and design specification document design: • Design– translates the requirements a completed design assessed for quality. model for a software product. into 7

Stages of Design • Problem understanding – Look at the problem from different angles to discover the design requirements. • Identify one or more solutions – Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. • Describe solution abstractions – Use graphical, formal or other descriptive notations to describe the components of the design. • Repeat process for each identified abstraction until the design is expressed in simple terms. 8

Software Design Process (Cont…) • A number of design methods can be used to produce software design: • Data design: transforms the information domain model into data structures. • Architecture design: defines the relationship among major structural elements of the program. • Interface design: describes how the software communicates with users. • Procedure design: transforms structural elements 10 of the program architecture into a procedural

The Design Model • Data Design – Transforms information domain model into data structures required to implement software • Architectural Design – Defines relationship among the major structural elements of a program Procedural Design Interface Design Architectural Design The Design Model Data Design

The Design Model • Interface Design – Describes how the software communicates with itself, to systems that interact with it and with humans. • Procedural Design – Transforms structural elements of the architecture into a procedural description of software construction Procedural Design Interface Design Architectural Design Data The Design Model Design

software architecture • A software architecture separates the overall structure of the system, in terms of components and their interconnections, from the internal details of the individual components. • programming-in-the-large • programming-in-the-small • software architecture can be described at different levels • The software quality attributes of a system should be considered when developing the software architecture

Features of Software Design • Common features of software design methods: • - A mechanism for translation of an analysis model into a design representation • - A notation for representing functional components and their interfaces • - Heuristics for refinement and partitioning • - Guidelines for quality assessment 14

The Design Process • Mc Glaughlin’s suggestions for good design: – Design must enable all requirements of the analysis model and implicit needs of the customer to be met – Design must be readable and an understandable guide for coders, testers and maintainers – The design should address the data, functional and behavioral domains of implementation 15

Design Guidelines • A design should exhibit a hierarchical organization • A design should be flexible • A design should contain both data and procedural abstractions • Modules should exhibit independent functional characteristics • Interfaces should reduce complexity • A design should be obtained from a repeatable method, driven by analysis 16

Design Methods: Procedural • Procedural Design • Transforms structural elements of the architecture into a procedural description of software construction • A design methodology combines a systematic set of rules for creating a program design with diagramming tools needed to represent it. • Procedural design is best used to model programs that have an obvious flow of data from input to output. • It represents the architecture of a program as a set of interacting processes that pass data from one to another. 17

Design Methods: Procedural • A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modelling its process aspects. • A DFD is often used as a preliminary step to create an overview of the system, which can later be elaborated. 18

Data Flow Diagrams (DFD) • DFDs describe the flow of data or information into and out of a system – what does the system do to the data? • A DFD is a graphic representation of the flow of data or information through a system 19

Software Design and Design Methods • Software Design is a process to convert requirement of customer into a blueprint form so that it will benefit the developer in the coding and implementation. • After design phase focus is shifted from problem domain to solution domain. • Software design can be represented textually or graphically. Examples class dia & pseudo code • A SW design method is a systematic way which portrays the series of steps to be followed for creating a design, based on the SW requirement given by customer. • A design method is based on a set of design concepts, employs one or more design strategies, and documents the resulting design using a design notation. • There are two design methods: 1. Structured / procedural 2. Object- Oriented

Structured / Procedural Design Method • It is based on divide and conquer strategy • A problem is broken down into a no of small problems and each small problem is individually solved until the whole problem is solved. • Structured design is concerned with solution design. • It helps in understanding how the problem can be solved. • It facilitates designer in focusing on the problem. • The small piece of problem are solved by means of solution modules. • The solution modules are arranged in hierarchical form. For creating a good design these modules need to communicate with each other using some rules , namely: Ø Minimize coupling between modules Ø Maximize cohesion between modules

Structure chart • Structure chart is the primary tool used in structure design. • The structure chart graphically depicts modular structure of SW. • The structure chart helps to partition program into small modules shows the hierarchy and of modules and communication between modules. • The structure chart uses following set of symbols: • Rectangles: It is used to represent modules. There is usually one main modules which is placed at top of the chart. • Connector: Every module is connected to all other modules which is directly calls by a connector. • Data Flow arrows: Arrow headed line with small circle at other end along with name of data on it is used to show flow of data

Object Oriented Design Method Objectives: • To explain how a software design may be represented as a set of interacting objects that manage their own state and operations • To describe the activities in the object- oriented design process • To introduce various models that can be used to describe an objectoriented design • To show the UML may be used to represent these models

Important terms in OO concepts: • Object: - It is an entity in the world which is having its own identity, behaviour state and responsibility. Objects are instance of a class, that interact with each other at runtime. In OOP programming object represents a entity that can store data and has its interface through functions. • Class: A class is like a blueprint for an object. It is a user defined data type, which holds its own data members and member functions. • In OOP everything is represented in the form of object. Objects interacts with each other by passing messages through methods.

Access Specifiers • defines the access rights for the statements or functions that follows it until another access specifier or till the end of a class. The three types of access specifiers are "private", "public", "protected". • private: The members declared as "private" can be accessed only within the same class and not from outside the class. • public: The members declared as "public" are accessible within the class as well as from outside the class. • protected: The members declared as "protected" cannot be accessed from outside the class, but can be accessed from a derived class. This is used when inheritance is applied to the members of a class.

Advantages of OOD • Easier maintenance. Objects may be understood as stand-alone entities. • Objects are potentially reusable components. • Mapping from real world entities to system objects.

Basic Principles of Object Oriented Technology 1. 2. 3. 4. 5. 6. 7. Abstraction Encapsulation Modularity Inheritance Polymorphism Abstract class Interface

• Abstraction: - Focus only on essential things which are needed in the given context and ignores non important ones. Consider only external behaviour without bothering internal details. Ex: not necessary in ATM machine how money is counted and balance is updated while withdrawing money from ATM. • Encapsulation: It describes the idea of bundling data and methods that work on that data within one unit, e. g. , a class in Java. This concept is also often used to hide the internal representation, or state, of an object from the outside. Data encapsulation led to the important OOP concept of data hiding.

• Modularity: - Decomposing a system into smaller, more manageable parts. Each smaller parts is a module which contain group of related classes. • Inheritance: - Inheritance is a mechanism in which one class acquires the property of another class. For example, a child inherits the traits of his/her parents. With inheritance, we can reuse the fields and methods of the existing class. Hence, inheritance facilitates Reusability and is an important concept of OOPs.

• Polymorphism: Polymorphism is a OOPs concept where one name can have many forms. It is ability to hide multiple implementations behind a single interface. For example, you have a smartphone for communication. The communication mode you choose could be anything. It can be a call, a text message, a picture message, mail, etc. So, the goal is common that is communication, but their approach is different. This is called Polymorphism. • Interface: An interface is a programming structure/syntax that allows the computer to enforce certain properties on an object (class). For example, say we have a car class and a scooter class and a truck class. Each of these three classes should have a start_engine() action.

Requirement Vs Analysis Vs Architecture Vs Design Vs Development Requirement Modeling: • It concern with the functional and non functional requirements of the system. • In Requirement Modeling system is considered as black box and use case model is developed. • Actors and use cases are defined which describe the functional requirements of the system. • Requirement Modeling also emphasis non functional requirements of the systems.

Analysis Modeling: • Analysis is breaking down or decomposing the problem. The focus is more on understanding the problem. Activities in analysis modeling are: • Static Modeling: structural view of the information is the static view of the problem. Classes are defined to describe the structural view. • Object structuring: Objects that interacts with the use cases are defined. Objects structuring criteria is used to define entry, boundary, control and application objects. • Dyanamic Interaction Modeling: The interaction bet the objects and use cases is shown using the communication dia or sequence dia. • Dyanamic State machine modeling: Finite state machine and state charts dia are uses to describes the state dependent view of the system.

Architectures: • It captures system structures in terms of components and how they interact. • All architecture is design but all design is not architecture. • It focuses in functional requirements of the system. • Architectures defines the guidelines stating the fundamental properties. • It is mainly used for communicating with business stakeholders.

Design: • • • It is used to define functional requirement of the system. It is the description of the detailed properties of the system. It focuses on individual components of the systems. Design is basically used for communicating with the SW developers. It is used to define SW methods, functions, objects and the overall structures and interaction of your code to fulfill requirement of customer. Development: • In this phase , the developers code the SW as mentioned in the design. • Development is the experimental part of the SDLC where the design is validated.

METHOD AND NOTATION • A software design notation is a means of describing a software design either graphically or textually, or both. For example, class diagrams • A software design concept is a fundamental idea that can be applied to designing a system. For example, information hiding is a software design concept. 24

Unified Modeling Language, Version 2. 0 • 2 types of diagrams • Structure Diagrams • Provide a way for representing the data and static relationships that are in an information system • Class diagram • Behavior Diagrams

Structure Diagrams • Class Diagram • Describe the structure of the system in terms of classes and objects • Primary purpose during analysis workflow: to create a vocabulary that is used by both the analyst and users

What is a Class? • A general template that we use to create specific instances or objects in the application domain • Represents a kind of person, place, or thing about which the system will need to capture and store information • Abstractions that specify the attributes and behaviors of a set of objects

What is an Object? • Entities that encapsulate state and behavior • Each object has an identity • It can be referred individually • It is distinguishable from other objects

Types of Classes • Ones found during analysis: • people, places, events, and things about which the system will capture information • ones found in application domain • Ones found during design • specific objects like windows and forms that are used to build the system

2 Kinds of Classes during Analysis • Concrete • Class from application domain • Example: Customer class and Employee class • Abstract • Useful abstractions • Example: Person class

Attributes in a Class • Properties of the class about which we want to capture information • Represents a piece of information that is relevant to the description of the class within the application domain

Attributes in a Class • Only add attributes that are primitive or atomic types • Derived attribute • attributes that are calculated or derived from other attributes • denoted by placing slash (/) before name

Operations in a Class • Represents the actions or functions that a class can perform • Describes the actions to which the instances of the class will be capable of responding • Can be classified as a constructor, query, or update operation

UML Representation of Class Name Attributes of Class Operations/methods of Class

Example of a Class Diagram Video Rental System visibility Customer -CID: int -name: String +authenticate. Customer () attributes multiplicity 1. . * rents 1. . * class name Video -cassette. ID : int -cassette. Volume. No: int +rent. Movie() relationship methods

Visibility of Attributes and Operations • Relates to the level of information hiding to be enforced

Visibility of Attributes and Operations Visibility Symbol Accessible To Public + All objects within your system. Protected # Instances of the implementing class and its subclasses. Private - Instances of the implementing class.

Relationships among Classes • Represents a connection between multiple classes or a class and itself • 3 basic categories: • association relationships • generalization relationships • aggregation relationships

Association Relationship • A bidirectional semantic connection between classes • Type: • name of relationship • role that classes play in the relationship

Association Relationship • Name of relationship type shown by: • drawing line between classes • labeling with the name of the relationship • indicating with a small solid triangle beside the name of the relationship the direction of the association Patient Provides Medical History

Association Relationship • Role type shown by: • drawing line between classes • indicating with a plus sign before the role name Patient + primary insurance carrier

Generalization Relationship • Enables the analyst to create classes that inherit attributes and operations of other classes • Represented by a-kind-of relationship

Generalization Relationship Person Employee Manager Engineer Customer

Generalization Relationship Employee hire. Date receive. Pay perform. Work Manager Engineer department certifications bonus hire. Employee analyze promote. Employee design

Generalization Relationship Person Employee Manager Engineer Contractor Preferred Contractor Secondary Contractor

Aggregation Relationship • Specialized form of association in which a whole is related to its part(s) • Represented by a-part-of relationship

Aggregation Relationship • Denoted by placing a diamond nearest the class representing the aggregation Patient 1 provides 0. . 1 Medical History

Multiplicity • Documents how many instances of a class can be associated with one instance of another class Patient 1 provides 0. . 1 Medical History

Multiplicity • Denotes the minimum number. . maximum number of instances Exactly one 1 Zero or more 0. . * or 0. . m One or more 1. . * or 1. . m Zero or one 0. . 1 Specified range 2. . 4 Multiple, disjoint ranges 1. . 3, 5

Class Diagram • 2 approaches to deriving class diagrams: • from use cases and their scenarios • from CRC cards

Deriving Class Diagram from Use Cases and Scenarios • Analyze the text in the use-case descriptions and scenarios

Guidelines for Analyzing Use Cases • A common or improper noun implies a class of objects • A proper noun implies an instance of a class • A collective noun implies a class of objects made up of groups of instances of another class

Guidelines for Analyzing Use Cases (2) • An adjective implies an attribute of an object • A doing verb implies an operation • A being verb implies a relationship between an object and its class • A having verb implies an aggregation or association relationship

Guidelines for Analyzing Use Cases (3) • A transitive verb implies an operation • An intransitive verb implies an exception • A predicate or descriptive verb phrase implies an operation • An adverb implies an attribute of a relationship or an operation

Class Diagram • Ensure that the classes are both necessary and sufficient to solve the underlying problem • no missing attributes or methods in each class • no extra or unused attributes or methods in each class • no missing or extra classes

Discarding Unnecessary and Incorrect Classes • Redundant Classes • Irrelevant Classes • Vague Classes • Attributes • Operations • Roles • Implementation Constructs

Software Design Static Modeling using the Unified Modeling Language (UML)

Classes Class. Name attributes operations A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments. Software Design (UML)

Class Names Class. Name attributes The name of the class is the only required tag in the graphical representation of a class. It always appears in the top-most compartment. operations Software Design (UML)

Class Attributes Person name : String address : Address birthdate : Date ssn : Id An attribute is a named property of a class that describes the object being modeled. In the class diagram, attributes appear in the second compartment just below the name-compartment. Software Design (UML)

Class Attributes (Cont’d) Attributes are usually listed in the form: Person name : String address : Address birthdate : Date / age : Date ssn : Id attribute. Name : Type A derived attribute is one that can be computed from other attributes, but doesn’t actually exist. For example, a Person’s age can be computed from his birth date. A derived attribute is designated by a preceding ‘/’ as in: / age : Date Software Design (UML)

Class Attributes (Cont’d) Person + name : String # address : Address # birthdate : Date / age : Date - ssn : Id Attributes can be: + public # protected - private / derived Software Design (UML)

Class Operations Person name : String address : Address birthdate : Date ssn : Id eat sleep work play Operations describe the class behavior and appear in the third compartment. Software Design (UML)

Class Operations (Cont’d) Phone. Book new. Entry (n : Name, a : Address, p : Phone. Number, d : Description) get. Phone ( n : Name, a : Address) : Phone. Number You can specify an operation by stating its signature: listing the name, type, and default value of all parameters, and, in the case of functions, a return type. Software Design (UML)

Depicting Classes When drawing a class, you needn’t show attributes and operation in every diagram. Person name : String birthdate : Date ssn : Id Person name address birthdate Person eat play Software Design (UML) eat() sleep() work() play()

Class Responsibilities A class may also include its responsibilities in a class diagram. A responsibility is a contract or obligation of a class to perform a particular service. Smoke. Alarm Responsibilities -- sound alert and notify guard station when smoke is detected. -- indicate battery state Software Design (UML)

Relationships In UML, object interconnections (logical or physical), are modeled as relationships. There are three kinds of relationships in UML: • dependencies • generalizations • associations Software Design (UML)

Dependency Relationships A dependency indicates a semantic relationship between two or more elements. The dependency from Course. Schedule to Course exists because Course is used in both the add and remove operations of Course. Schedule Course add(c : Course) remove(c : Course) Software Design (UML)

Generalization Relationships Person Student A generalization connects a subclass to its superclass. It denotes an inheritance of attributes and behavior from the superclass to the subclass and indicates a specialization in the subclass of the more general superclass. Software Design (UML)

Generalization Relationships (Cont’d) UML permits a class to inherit from multiple superclasses, although some programming languages (e. g. , Java) do not permit multiple inheritance. Student Employee Teaching. Assistant Software Design (UML)

Association Relationships If two classes in a model need to communicate with each other, there must be link between them. An association denotes that link. Student Instructor Software Design (UML)

Association Relationships (Cont’d) We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association. The example indicates that a Student has one or more Instructors: Student 1. . * Software Design (UML) Instructor

Association Relationships (Cont’d) The example indicates that every Instructor has one or more Students: Student Instructor 1. . * Software Design (UML)

Association Relationships (Cont’d) We can also indicate the behavior of an object in an association (i. e. , the role of an object) using rolenames. Student teaches 1. . * learns from 1. . * Software Design (UML) Instructor

Association Relationships (Cont’d) We can also name the association. Student membership 1. . * Software Design (UML) Team

Association Relationships (Cont’d) We can specify dual associations. member of Student 1. . * 1 1. . * president of 1. . * Software Design (UML) Team

Association Relationships (Cont’d) We can constrain the association relationship by defining the navigability of the association. Here, a Router object requests services from a DNS object by sending messages to (invoking the operations of) the server. The direction of the association indicates that the server has no knowledge of the Router Domain. Name. Server Software Design (UML)

Association Relationships (Cont’d) Associations can also be objects themselves, called link classes or an association classes. Registration model. Number serial. Number warrenty. Code Product Warranty Software Design (UML)

Association Relationships (Cont’d) A class can have a self association. next Linked. List. Node previous Software Design (UML)

Association Relationships (Cont’d) We can model objects that contain other objects by way of special associations called aggregations and compositions. An aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part, where the part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornment on the association. Engine Car Transmission Software Design (UML)

Association Relationships (Cont’d) A composition indicates a strong ownership and coincident lifetime of parts by the whole (i. e. , they live and die as a whole). Compositions are denoted by a filled-diamond adornment on the association. 1 Window 1 1 1. . * Software Design (UML) Scrollbar Titlebar Menu

Interfaces <<interface>> Control. Panel An interface is a named set of operations that specifies the behavior of objects without showing their inner structure. It can be rendered in the model by a one- or two-compartment rectangle, with the stereotype <<interface>> above the interface name. Software Design (UML)

Interface Services <<interface>> Control. Panel get. Choices : Choice[] make. Choice (c : Choice) get. Selection : Selection Interfaces do not get instantiated. They have no attributes or state. Rather, they specify the services offered by a related class. Software Design (UML)

Interface Realization Relationship <<interface>> Control. Panel specifier implementation A realization relationship connects a class with an interface that supplies its behavioral specification. It is rendered by a dashed line with a hollow triangle towards the specifier. Vending. Machine Software Design (UML)

Interfaces input. Stream {file must not be locked} File. Writer A class’ interface can also be rendered by a circle connected to a class by a solid line. File {file must exist} output. Stream Software Design (UML) File. Reader

Parameterized Class T Linked. List T 1. . * A parameterized class or template defines a family of potential elements. To use it, the parameter must be bound. A template is rendered by a small dashed rectangle superimposed on the upper-right corner of the class rectangle. The dashed rectangle contains a list of formal parameters for the class. Software Design (UML)

Parameterized Class (Cont’d) T Linked. List T 1. . * <<bind>>(Name) Binding is done with the <<bind>> stereotype and a parameter to supply to the template. These are adornments to the dashed arrow denoting the realization relationship. Here we create a linked-list of names for the Dean’s List. Deans. List Software Design (UML)

Enumeration <<enumeration>> Boolean false true An enumeration is a user-defined data type that consists of a name and an ordered list of enumeration literals. Software Design (UML)

Exceptions <<exception>> Exceptions can be modeled just like any other class. get. Message() print. Stack. Trace() Notice the <<exception>> stereotype in the name compartment. <<exception>> Key. Exception <<exception>> SQLException Software Design (UML)

Packages A package is a container-like element for organizing other elements into groups. Compiler A package can contain classes and other packages and diagrams. Packages can be used to provide controlled access between classes in different packages. Software Design (UML)

Packages (Cont’d) Classes in the Front. End package and classes in the Back. End package cannot access each other in this diagram. Compiler Front. End Back. End Software Design (UML)

Packages (Cont’d) Classes in the Back. End package now have access to the classes in the Front. End package. Compiler Front. End Back. End Software Design (UML)

Packages (Cont’d) Compiler We can model generalizations and dependencies between packages. Java. Compiler Java Software Design (UML)

Component Diagram Component diagrams are one of the two kinds of diagrams found in modeling the physical aspects of an object-oriented system. They show the organization and dependencies between a set of components. Use component diagrams to model the static implementation view of a system. This involves modeling the physical things that reside on a node, such as executables, libraries, tables, files, and documents. - The UML User Guide, Booch et. al. , 1999 Software Design (UML)

Component Diagram path. dll collision. dll driver. dll version = 8. 1. 3. 2 IDrive ISelf. Test Software Design (UML) Here’s an example of a component model of an executable release. [Booch, 99]

Component Diagram signal. h version = 3. 5 “parent” signal. h version = 4. 0 signal. h version = 4. 1 “parent” signal. cpp version = 4. 1 interp. cpp Modeling source code. [Booch, 99] irq. h Software Design (UML) device. cpp

Deployment Diagram Deployment diagrams are one of the two kinds of diagrams found in modeling the physical aspects of an object-oriented system. They show the configuration of run-time processing nodes and the components that live on them. Use deployment diagrams to model the static deployment view of a system. This involves modeling the topology of the hardware on which the system executes. - The UML User Guide, [Booch, 99] Software Design (UML)

Deployment Diagram A component is a physical unit of implementation with welldefined interfaces that is intended to be used as a replaceable part of a system. Well designed components do not depend directly on other components, but rather on interfaces that components support. - The UML Reference Manual, [Rumbaugh, 99] component spell-check Dictionary Software Design (UML) synonyms interfaces

Deployment Diagram stereotyped component <<database>> Account Transactions Update interface usage dependency component ATM-GUI realization dependency [Rumbaugh, 99] Software Design (UML)

Deployment Diagram server: Host. Machine <<database>> meetings. DB : Scheduler reservations Deployment diagram of a client-server system. <<direct channel>> [Rumbaugh, 99] client. Machine: PC : Planner Software Design (UML)

Software Design Dynamic Modeling using the Unified Modeling Language (UML) Software Design (UML)

Use Case “A use case specifies the behavior of a system or a part of a system, and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor. ” - The UML User Guide, [Booch, 99] “An actor is an idealization of an external person, process, or thing interacting with a system, subsystem, or class. An actor characterizes the interactions that outside users may have with the system. ” - The UML Reference Manual, [Rumbaugh, 99] Software Design (UML)

Use Case (Cont’d) Register for Courses Software Design (UML) A use case is rendered as an ellipse in a use case diagram. A use case is always labeled with its name.

Use Case (Cont’d) An actor is rendered as a stick figure in a use case diagram. Each actor participates in one or more use cases. Student Software Design (UML)

Use Case (Cont’d) Actors can participate in a generalization relation with other actors. Student Software Design (UML) Person

Use Case (Cont’d) Actors may be connected to use cases only by associations. Register for Courses Student Software Design (UML)

Use Case (Cont’d) Here we have a Student interacting with the Registrar and the Billing System via a “Register for Courses” use case. Billing System Student Register for Courses Registrar Software Design (UML)

State Machine “The state machine view describes the dynamic behavior of objects over time by modeling the lifecycles of objects of each class. Each object is treated as an isolated entity that communicates with the rest of the world by detecting events and responding to them. Events represent the kinds of changes that objects can detect. . . Anything that can affect an object can be characterized as an event. ” - The UML Reference Manual, [Rumbaugh, 99] Software Design (UML)

State Machine An object must be in some specific state at any given time during its lifecycle. An object transitions from one state to another as the result of some event that affects it. You may create a state diagram for any class, collaboration, operation, or use case in a UML model. There can be only one start state in a state diagram, but there may be many intermediate and final states. Software Design (UML)

State Machine start state final state simple state concurrent composite state sequential composite state Software Design (UML)

State Machine download course offerings downloading unscheduled make a course selection selecting make a different selection verifying check schedule sign scheduled Software Design (UML) checking schedule select another course

Sequence Diagram A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. It shows a set of objects and the messages sent and received by those objects. Graphically, a sequence diagram is a table that shows objects arranged along the X axis and messages, ordered in increasing time, along the Y axis. - The UML User Guide, [Booch, 99] Software Design (UML)

Sequence Diagram an Order Line An object in a sequence diagram is rendered as a box with a dashed line descending from it. The line is called the object lifeline, and it represents the existence of an object over a period of time. Software Design (UML)

Sequence Diagram an Order Line a Stock Item Messages are rendered as horizontal check() [check = “true”] remove() arrows being passed from object to object as time advances down the object lifelines. Conditions ( such as [check = “true”] ) indicate when a message gets passed. Software Design (UML)

Sequence Diagram an Order Line a Stock Item check() [check = “true”] remove() Notice that the bottom arrow is different. The arrow head is not solid, and there is no accompanying message. This arrow indicates a return from a previous message, not a new message. Software Design (UML)

Sequence Diagram an Order a Order Line * prepare() Iteration marker Software Design (UML) An iteration marker, such as * (as shown), or *[i = 1. . n] , indicates that a message will be repeated as indicated.

an Order Entry window an Order Line prepare() Condition * prepare() Object [Fowler, 97] a Stock Item check() [check = “true”] remove() Message needs. To. Reorder() Iteration Self-Delegation Return [needs. To. Reorder = “true”] new A Reorder Item [check = “true”] new A Delivery Item Creation Software Design (UML)

Collaboration Diagram A collaboration diagram emphasizes the relationship of the objects that participate in an interaction. Unlike a sequence diagram, you don’t have to show the lifeline of an object explicitly in a collaboration diagram. The sequence of events are indicated by sequence numbers preceding messages. Object identifiers are of the form object. Name : class. Name, and either the object. Name or the class. Name can be omitted, and the placement of the colon indicates either an object. Name: , or a : class. Name. Software Design (UML)

Collaboration Diagram Object : Order Entry Window 1: prepare() : Order 2*: prepare() Message Self-Delegation 5: need. To. Reorder() 3: check() 4: [check == true] remove() : Order Line 7: [check == true] new : Delivery Item Sequence Number : Stock Item 6: new : Reorder Item [Fowler, 97] Software Design (UML)

Collaboration Diagram Sequence Diagram Both a collaboration diagram and a sequence diagram derive from the same information in the UML’s metamodel, so you can take a diagram in one form and convert it into the other. They are semantically equivalent. Software Design (UML)

Activity Diagram An activity diagram is essentially a flowchart, showing the flow of control from activity to activity. Use activity diagrams to specify, construct, and document the dynamics of a society of objects, or to model the flow of control of an operation. Whereas interaction diagrams emphasize the flow of control from object to object, activity diagrams emphasize the flow of control from activity to activity. An activity is an ongoing non-atomic execution within a state machine. - The UML User Guide, [Booch, 99] Software Design (UML)

[Fowler, 97] Receive Order Multiple Trigger * Cancel Order [failed] Authorize Payment [succeeded] for each line item on order Check Line Item [in stock] Assign to Order Synchronization Condition [need to reorder] [stock assigned to all line items and payment authorized] Dispatch Order Software Design (UML) Reorder Item

4+1 View Model of Software Architecture

4+1 View Model of Architecture End user Logical view Programmers & software managers Development view Use Case View Process View Integrator Deployment View System Engineer 131

Use –case View • It shows functionality which delivered by system to external actors. • An actor interacts with the system. Actor can be device, human or another system. • Use case view is used by customers, designer, developers and testers. • Use case is central bcoz its content drive the other view developement. 132

Logical View • It shows how the systems functionality is provided. It is mainly for designer and developers. • The logical view looks inside the system. It describe both static structure and dynamic collaborations. • The static structure is described in class and object dia. The dynamic behavior is described in state machine, interaction and activity diagrams. 133

1. Logical Architecture (View) • Logical view primarily describes the services provided to the users. The system is decomposed into key abstractions (e. g. classes) that describe the functional requirements. • May include the identification of common components across the system. • Uses OO Approach &Class Diagrams, which shows • i) Classes and • ii) the Relationships (inheritance, composition, usage, etc. ) among Classes • Alternative to OO, may use E-R diagrams for data driven systems

Logical Architecture (View) cont. • Notation used for the OO approach of Logical View is derived from Booch and include: • A) Components --- Class; Class Utility; Parameterized Class; Class Category • B) Connectors --- Various Relationships of Association; Containment & Aggregation; Usage; Inheritance; Instantiation • Style: • Object Oriented Style class usage inheritance • A Logical Blueprint • Some pictorial representation, using Booch Notation, of the logical view of a design.

Process View It deals with the division of the system into processes and processors. A view showing main elements in the system related to process performance. This view includes scalability, throughput, and basic time performance and can touch on some very complex calculations for advanced systems. 136

Process view (cont. ) • Uses multiple levels of abstractions, a logical network of processes at the highest level • A process is a grouping of tasks that form an executable unit: • Major Tasks: Arch. relevant tasks • Minor Tasks: Helper tasks. (Buffering) 137

2. Process Architecture (View) • Process view primarily describes the a) non-functional aspects of the requirements and b) execution control such as the performance or integrity and addresses issues such as concurrency or distribution • Describes the thread of control of an operation of how a process (i. e. set of tasks) is executed. • Process is a set of tasks that form an executable unit which can be started, controlled, terminated, etc. ) • A task is a “smaller” thread of control that can be individually scheduled on one processing node • Tasks also communicate via some well defined mechanism • Process i) loads and ii) flow of messages can be estimated via studying a blueprint of process view.

Process Architecture (View) cont. • Notation used for Process View is derived from Booch’s proposal for Ada tasking and includes: • A) Components --- Process; Simplified Process; Periodic Process adornment • B) Connectors ---- Unspecified; Message (unidirectional and bidirectional); Remote Procedure Call; Event Broadcast message simplified process RPC • Process Blueprint: • Some diagram, using the defined notation, to depict the flow of messages from process to process.

Process View example 140

Development Viewer: Programmers and Software Managers It consist of the main SW artifacts. It is mainly for developers. The artifacts includes different types of code modules shown with their structure dependencies. 141

3. Development Architecture (View) • Development view focuses on the software module organization as they are packaged into small units of subsystems or libraries that can be developed by a small unit of developers. • The rules that govern the development architecture may include: partitioning; grouping; visibility • Takes into account of the “internal requirements” related to development, project management, re-use, toolset constraints, development platform and language constraints, etc.

Development Architecture (View) cont. • Notation used for development view is again derived from Booch: • Components ---- Module; Subsystem; Layer • Connectors ---- References; Compilation Dependency layer subsystem module reference • Development Blueprint: • Some diagram depicting the layers of a software system that matches the logical view of the same system. Contained within each layer are several subsystems, which in turn may contain several modules.

Deployment View (Mapping the software to the Hardware) Viewer: System Engineers • It shows physical deployment of the system such as computers and devices and how they connect to each other. • The deployment view is used by developers, integrator and testers is represented by the deployment dia. . • No modeler can generate a single dia that defines the entire system unambiguously and understandable by all human beings looking at it. 144

4. Deployment Architecture (View) • Physical view focuses on the non-functional requirements of the “hardware” system on top of which the software resides. • The various elements identified are parts of the physical configuration needed to run the software • These may include nodes, processors, devices, lines/channels, etc. • The configurations may be for development purpose, for testing purpose, deployment purpose, etc.

Deployment Architecture (View) cont. • Notations used are pretty much box and line: • Components --- processors; devices • Connectors --- communication lines; high bandwidth bus processor device comm. line high bandwidth communications • Style: • There is no specific style except possibly hierarchical • Physical Blueprint: • Diagram depicting the “process architecture” mapped onto the “physical architecture. ”